On 5/14/14, Trevor Perrin <[email protected]> wrote: > On Wed, May 14, 2014 at 5:04 PM, Robert Ransom <[email protected]> > wrote: >> On 5/14/14, Trevor Perrin <[email protected]> wrote: >>> >>> Such a mutual-auth Ace would be similar to NIST SP 800-56B's "full >>> unified model", right? I.e. it would perform a static-static DH and >>> an ephemeral-ephemeral DH, then combine them into a session key. >>> >>> So wouldn't it have a "key-compromise-impersonation" weakness, where >>> if I compromise your private key, I can impersonate anyone else to you >>> by calculating the static-static DH? >> >> It would. (I don't think that's a serious problem for a protocol to >> have, given that if you compromise Bob's long-term secret key, you can >> also impersonate Bob to everyone else.) > > Maybe, but other protocols resist KCI.
If you want that feature in a mutual-authentication protocol, you could use CDH(P, A, Y_1) + CDH(P, X_1, B) + CDH(P, Y_1, Y_2) as the secret input to the KDF. I don't think it's worth the added cost. > I see that Ace's use of Shamir simultaneous exponentiation makes it > fast. My sense is that modern curves are so fast we mostly don't have > to resort to this, which is why I'm a little skeptical of Ace or MQV > over simpler DH-based protocols (e.g. I think Tor isn't replacing Ntor > with Ace)? > > That said, I'm sure there's cases where that speed matters. The advantages of Ace or a mutual-authentication variant of it are that they are simpler to implement than a signature scheme (no scalar operations needed), and faster (for similarly optimized software, on an Edwards/Montgomery curve) than ntor. >>> Not sure what you mean, don't things like Ntor and TripleDH require >>> ephemeral and long-term keys to be on the same curve? >> >> In ntor, the client sends X, the server publishes long-term key B and >> sends Y, and the shared secret key is H(X, B, Y, CDH(P, X, B), CDH(P, >> X, Y)). The only reason that the ephemeral forward-secrecy key Y >> needs to be on the same curve as B is that the client only sends one >> ephemeral key X, to be used for both authentication verification and >> forward secrecy. >> >> This can easily be modified to use two separate groups: > > Ah, nice! > > So you could use a faster curve for ephemeral-static DH > (authentication) and a larger curve for ephemeral-ephemeral DH > (long-term confidentiality), thus accelerating 1/2 (Ntor) or 2/3 > (TripleDH) of the DHs... Or a smaller curve for the authentication (e.g. ‘human-friendly’ keys on a curve mod 2^206 - 5 or 2^205 - 45*2^198 - 1), and a larger, more heavily optimized curve like Curve25519 for forward secrecy. Or a widely implemented ‘least common denominator’ curve like Curve25519 for the long-term authentication keypair, and a faster curve at the same security level (e.g. the Gaudry-Schost genus-2 curve or Hamburg's ‘Montgomery Station’ curve or, in the distant future, some GLV/GLS curve) when both parties happen to have support for it. Robert Ransom _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
