[messaging] Fwd: saltpack spec and library

[Jack O'Connor]

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 https://github.com/dchest/ed2curve-js 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160203/565310b0/attachment.html>