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
Henry de Valence pfp
Henry de Valence
@hdevalence
neat, what’s the basic shape of the integration? are clues going to be bundled into transactions, or just posted to a separate scanning layer? how does the address <> clue key lookup work?
1 reply
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
Haven't thought of better way for address <> clue key lookup than naively posting on the internet. If there's some progress, will keep you updated! Current hope is to bundle clues with transactions, but it's still early to confirm this.
1 reply
0 recast
0 reaction
Henry de Valence pfp
Henry de Valence
@hdevalence
hmm, can an attacker do anything by interfering with the address/clue key resolution? would it make sense to have something like a merklized transparency log of the clue keys? or, if the clue keys are subordinate to the address, can they be signed by the address and verified that way?
2 replies
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
by interfering with resolution of lookup the attacker can make the message go to some other user ~ to which the resolved clue key belongs. So an attacker can spam an individual, or a group, by resolving most lookups to their clue keys. Since OMR caps msgs that can be pertinent to a user at once to max value(ex. 50)...
1 reply
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
...beyond which the digest sent to them becomes useless, this can result in targeted individuals not receiving important msgs. I think having either of merklized transparency log/signature on clues will be helpful! Also we only require separate clue keys because we don't have efficient eval circuit of decryption...
1 reply
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
...algorithm of encryption schemes used in blockchains. If some magic happens in future and we figure out an efficient way to homomorphically decrypt encrypted msgs, then we can get rid of separate clues.
1 reply
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
I should clarify msgs "cap" in OMR. So given set of all messages, if more than `k` msgs are pertinent to a user, the digest sent to them consisting all their pertinent msgs will be useless. An attacker can cause this by posting msgs > k for some user. However we can change the `k` on the fly! User can...
1 reply
0 recast
0 reaction
Janmajaya Mall pfp
Janmajaya Mall
@jmall
...increase `k` in subsequent requests to the server. These requests will have a bit higher latency, but works.
0 reply
0 recast
0 reaction