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

[William Whyte]

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] *On Behalf Of *Tony
Arcieri
*Sent:* Tuesday, April 08, 2014 9:18 PM
*To:* 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20140408/17244a26/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6099 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20140408/17244a26/attachment.bin>