<div dir="ltr"><div class="gmail_quote">Thanks for the comments, Trevor, this is incredibly helpful. I have some followup questions if you have time. > (1) If two recipient public keys are identical, this fact would leak > in the ciphertext. If I'm one of the recipients I could possibly use > this to confirm guesses as to other recipients, by providing their > public keys as mine. Good catch, we should totally fix that. It looks like there's two places where sharing a nonce among the recipients causes this problem: 1) when we box the payload encryption key for each recipient, and 2) when we compute each recipient's MAC key. I think we could fix both cases by putting a 4-byte counter at the end of each of the nonces. (MessagePack's biggest array type has a 4-byte length, so this is already the theoretical limit on our number of recipients.) Out of curiosity, since we're relying on random nonce #2 to avoid nonce reuse between two static keys, is there a size that's generally considered safe for that? This change would drop us from 24 random bytes down to 20. Thinking about this attack brought up a related problem: currently there's no way for Keybase users to publicly prove that they own a particular encryption key. Instead, they just claim ownership with a signed statement from one of their signing keys. So the only protection I have against you claiming my encryption key as your own, is that the server can refuse to allow repeats (and make that policy auditable through our Merkle tree). That's not great. How risky would it be to use an approach like <a href="https://github.com/dchest/ed2curve-js" rel="noreferrer" target="_blank">https://github.com/dchest/ed2curve-js</a> to convert a Curve25519 encryption key into an Ed25519 signing key, just one time when the key is created, to sign a statement about who owns it? > (2) The MAC keys only depend on the static-static DH output, not the > ephemeral-static DH output. So if I compromise Alice's private key, I > can tamper with the ciphertext of messages she's previously produced. > This would be easy to avoid, if the ephemeral-static DH outputs > contributed to the MAC keys. Could you help me picture the attack here? If I've stolen Alice's private key, I can always generate entirely new messages that appear to be from her. Is there a situation where reusing one of Alice's old message headers / ephemeral keys is required? > (3) On a similar note, it wouldn't hurt if the static-static DH > outputs contributed to the key used for encrypting payloads. That > *might* help in the case where a weak RNG is generating bad ephemeral > private keys, but somehow the sender's static private key was good. > But that's a pretty weird case. The static-static DH outputs are unique for each recipient, but the payload encryption key needs to be shared. Is there a way to make that work? Thanks again, Trevor. I'm really glad this list is here. - Jack </div> </div>