[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Thu Oct 3 12:40:05 EDT 2013

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

> Perhaps we can combine some of the advantages of fingerprints and SAS:

Sure, and I should point out that fingerprints, SAS, and PAKE could all be
done in parallel.  For example, OTR offers all three (session IDs = SAS;
Socialist Millionaire's Protocol = PAKE).

> * The introducees exchange single-use public keys, signed with their
> long-term private keys, via the introducer
> * The introducees derive a shared secret, destroy their single-use
> private keys, and start key rotation

Having each party sign an ephemeral public key with a long-term signing key
is not, by itself, a good key agreement protocol, due to:

 * The "identity misbinding" possibility of an an attacker signing a
victim's ephemeral key, tricking others into thinking the victim's
communications originated from the attacker.

 * The lack of freshness on the authentication - if an attacker compromises
one ephemeral private key, it can be reused without needing additional

Earlier I was suggesting "triple Diffie-Hellman" as a better option.

> * 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, signed with their long-term private keys, as verification that
> they own those keys and have the same shared secret
> * Nobody signs anything that proves who their contacts are

If you care about deniability I would avoid signatures entirely (e.g. use
Diffie-Hellman based protocols).

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

More information about the cryptography mailing list