Janmajaya Mall pfp
Janmajaya Mall
@jmall
Checkout my demo of Oblivious message retrieval (OMR) - https://github.com/Janmajayamall/ObliviousMessageRetrieval. If you find this interesting then let's work together :) 1/n
2 replies
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
What's OMR ? It's a way for an untrusted server to send you pertaining messages/transactions from set of all messages without ever learning which ones actually do! 2/n
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
It's very useful for privacy focussed blockchains / messaging apps, since it allows mobile/light clients to receive latest messages pertaining to them without trusting servers. You can learn more about OMR on readme of github link above. 3/n
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
I am working on implementing OMR for wide adoption so that privacy focussed app/blockchain users don't have to trust servers! The implementation linked above isn't quite there yet, but I am working on improving it! For ex - adding SIMD support for underlying fhe library - https://github.com/Janmajayamall/fhe.rs 4/n
2 replies
0 recast
0 reaction

Henry de Valence pfp
Henry de Valence
@hdevalence
what are the key sizes like?
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
the detection key uploaded to server by client is of size 20.2 MB.
1 reply
0 recast
0 reaction

Henry de Valence pfp
Henry de Valence
@hdevalence
wow, that’s a big improvement over the original paper. what are the sizes of the clue keys / clues? for penumbra we went with fmd because the clue key can be just 32 bytes, so we can include them in every address and the anonymity set is the whole userbase, rather than just the people using detection
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
Thanks! clue keys = 133kb and clues = 956 bytes (both same as paper). I haven't done anything new with detection key. Just reduced the polynomial size of ciphertexts from 2^15 to 2^11. This reduces evaluation time of messages by a lot but also reduces no. of messages that can be processed on a single core at once...
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
...however we can always increase no. of cores to accommodate more traffic. Yeah, I understand that having 133kb clue key isn't ideal for blockchains. I think authors of OMR paper are in the process of integrating OMR with Zcash. Curious to see how they approach it.
1 reply
0 recast
0 reaction

Henry de Valence pfp
Henry de Valence
@hdevalence
will be interesting to see. my instinct is that in practice, probabilistic privacy relative to the entire userbase will end up being better than stronger guarantees relative to a small subset who opt in to using the system, which is why we went for FMD
1 reply
0 recast
0 reaction

Henry de Valence pfp
Henry de Valence
@hdevalence
like once you have a clue key in every address, you can have clues in every transaction, regardless of whether or not the sender or receiver actually use the detection system
1 reply
0 recast
0 reaction

Janmajaya Mall pfp
Janmajaya Mall
@jmall
yeah this makes sense. But we can experiment with both approaches and figure out what works best. I am working on implementing this for Aztec. So we likely have some data on how FMD compares with OMR in blockchain context.
1 reply
0 recast
0 reaction