[cryptography] Asynchronous forward secrecy encryption

Michael Rogers michael at briarproject.org
Thu Oct 3 12:57:44 EDT 2013

Hash: SHA1

On 03/10/13 17:40, Trevor Perrin wrote:
> 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 signatures.
> Earlier I was suggesting "triple Diffie-Hellman" as a better
> option.
> If you care about deniability I would avoid signatures entirely
> (e.g. use Diffie-Hellman based protocols).

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? Have you patented 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
* 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

I've avoided triple-DH in the confirmation protocol so that long-term
public keys aren't sent in the clear.


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the cryptography mailing list