[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Thu Oct 3 13:44:12 EDT 2013

On Thu, Oct 3, 2013 at 9:57 AM, Michael Rogers <michael at briarproject.org>wrote:

> Great points, thanks! I'd forgotten about triple Diffie-Hellman
> (already, tut tut). Has it received any peer review other than being
> adopted by Moxie?

It was analyzed in a paper by Kudla & Paterson.  See Section 5.1, and the
note near the end that "Protocol 1 can easily be extended to have perfect
forward secrecy [...]".


The Ntor protocol by Goldberg et al is also similar.  It's essentially a
server-authenticated (instead of mutually-authenticated) version of this,
so it's a "double-DH" (omitting the ephemeral-static DH that would involve
the client's static key).  I believe Ntor is being considered for use in


> Have you patented it? ;-)

No, nor am I aware of any patents or IPR covering it.

> So a triple-DH version of the protocol would look like this:
> * The introducees exchange single-use public keys and long-term public
> keys via the introducer
> * The introducees use triple-DH to derive a shared secret, destroy
> their single-use private keys, and start key rotation

To state the obvious, you'll need to be quite careful with key derivation
from the 3 ECDH secrets, e.g. also hash in all relevant public keys and
other identifiers, handshake messages, etc., perhaps using something like

> * The introducees exchange acks via the introducer
> * The introducees can optionally obtain each other's long-term public
> keys from other third parties, before or after the introduction
> * If the introducees meet face-to-face, they can confirm each other's
> long-term public keys using SAS:
>   - The users verbally exchange short codes to enable their devices to
> find each other over a short-range transport such as wifi
>   - The devices exchange hash commitments and ephemeral public keys
>   - The users verbally exchange short authentication strings
>   - If the strings match, the devices derive symmetric encryption and
> authentication keys from the ephemeral shared secret
>   - Within the ephemeral secure channel, the devices exchange
> long-term public keys and a value derived from the current temporary
> secret as verification that they have the same shared secret
> * Nobody signs anything at all

Nothing horrible jumps out at me, though I'm not saying that's a thorough

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20131003/468c35bf/attachment.html>

More information about the cryptography mailing list