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:[email protected]] *On Behalf Of *Tony Arcieri *Sent:* Tuesday, April 08, 2014 9:18 PM *To:* [email protected] *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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
