[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Tue Sep 24 02:52:22 EDT 2013

On Mon, Sep 23, 2013 at 4:51 AM, Michael Rogers
<michael at briarproject.org> wrote:
> Hash: SHA1
> Thanks Trevor and Adam for your comments on this - I take your point
> about the importance of forward secrecy for metadata, so I'll abandon
> the idea of using ephemeral-static ECDH to protect the metadata.

You could update the "static" ECDH keys used for metadata encryption,
so these aren't necessarily exclusive.  But since you'll probably need
trial decryption for different conversations, I can see why you might
prefer more efficient symmetric crypto.

Ephemeral-static ECDH is still a nice way to add "sender forward
secrecy" though, since compromise of sender private keys wouldn't
allow decryption of sent messages.  So it could be used with other
forward-secrecy techniques.  For example, Pond uses an OTR-like
"Diffie-Hellman ratchet", but adds an extra ephemeral-static ECDH per
message [1].

> The key agreement starts with a hash commitment, followed by an
> exchange of ephemeral ECDH public keys. Two short authentication
> strings (again, six decimal digits) are derived from the shared
> secret; the users exchange the authentication codes verbally to
> complete the process.

Sounds reasonable but you'll need a 3-way handshake for the short auth
strings, which could be awkward in an "asynchronous messaging"

>> (Elligator + DH-EKE makes a nice PAKE, fwiw.)
> Thanks, I'll look into it. The protocol I described above is (loosely
> ZRTP-inspired) homebrew, and it would be nice to move to something
> more standard.

Oh, that's not standard at all, it may even need something weird like
a cipher with 256-bit block length... but should be doable [2].


[1] See "Message encryption" at:

[2] See "EKE2" at:

More information about the cryptography mailing list