[curves] Forward secrecy with "triple Diffie-Hellman"

[Feng Hao]

Just looking at this description, a (very) minor comment is that each party needs to not only keep the static key secure, but also to keep S (a static value) secret. If S is revealed, the effect is equivalent to having the long-term private key revealed within the context of two-party communication. In addition, you may also need to include the user identities somewhere (to prevent unknown key sharing attacks), either in the key exchange flows or in the key derivation. If you take all these into account, you will probably come to something similar to Naxos.

In 2010, I wrote a paper published at FC'10 (https://eprint.iacr.org/2010/136.pdf) and described a different approach. Rather than listing triple DH in separate terms, I argued it may be better to merge them in just one term as follows (G is the base point, a,b are static keys and a', b' are ephemeral):

Alice -> Bob: a'G, ZKP{a'}
Bob -> Alice: b'G, ZKP{b'}

K = KDF( (a+a') (b+b') G ).

Although it uses ZKP (Schnorr in particular), the overall efficiency is comparable to that in NAXOS (see Table 1 on p. 9 in the above link), but the protocol is simpler and neater. Personally, I prefer simplicity than complexity.

There is also short summary of the protocol at http://en.wikipedia.org/wiki/YAK_%28cryptography%29

Cheers,
Feng

From: William Whyte <wwhyte at securityinnovation.com<mailto:wwhyte at securityinnovation.com>>
Date: Tue, 8 Apr 2014 22:31:55 -0400
To: Tony Arcieri <bascule at gmail.com<mailto:bascule at gmail.com>>, "curves at moderncrypto.org<mailto:curves at moderncrypto.org>" <curves at moderncrypto.org<mailto:curves at moderncrypto.org>>
Subject: Re: [curves] Forward secrecy with "triple Diffie-Hellman"

My understanding, though I’m having trouble tracking down the reference at the moment, is that standard ephemeral-static DH has good properties and takes one less exponentiation:

  S = aB = bA
  S’ = a’B’ = b’A’
  K = KDF (S || S’)

Do you have a reason to prefer the triple version?

This version is defined in X9.42 as dhHybrid1, and X9.42 contains various security claims about the properties of this approach, but it was written in 2003 and analysis has got more rigorous since then so there may be more up-to-date statements about it.

Cheers

William


From: Curves [mailto:curves-bounces at moderncrypto.org<mailto:curves-bounces at moderncrypto.org>] On Behalf Of Tony Arcieri
Sent: Tuesday, April 08, 2014 9:18 PM
To: curves at moderncrypto.org<mailto:curves at moderncrypto.org>
Subject: [curves] Forward secrecy with "triple Diffie-Hellman"

Trevor described this idea to me once and I haven't really seen it written down anywhere. It's an alternative to something like the CurveCP handshake for a transport encryption protocol which provides forward secrecy by deriving a unique session key each time using ephemeral D-H keys. It couples authentication to confidentiality in ways that might bother some, but at the same time is incredibly simple and I think that's an advantage in and of itself.

Let's say Alice has the following elliptic curve D-H keys:

a: long-lived private key
A: long-lived public key

Alice will also generate a' and A' for each session, which are short-lived session keys.

Bob likewise has b, B , b', and B' respectively.

Alice can do:

  a * B' || a' * B' || a' * B

(The "*" character here represents Curve25519 scalar multiplication)

Bob can do the reciprocal operation and derive the same shared secret string:

  b * A' || b' * A' || b' * A

These secret strings can then be used as input to a KDF to create a session key.

If these keys haven't been tampered with in-flight, Alice and Bob should derive the same session key, and can authenticate each other via their long-lived public keys.

Does this seem correct, and if so, does anyone know of any literature on this approach?

--
Tony Arcieri
_______________________________________________ Curves mailing list Curves at moderncrypto.org<mailto:Curves at moderncrypto.org> https://moderncrypto.org/mailman/listinfo/curves
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20140409/3b60dba7/attachment.html>