On 5/14/14, Trevor Perrin <[email protected]> wrote: > On Wed, May 14, 2014 at 2:38 PM, Robert Ransom <[email protected]> > wrote: >> On 5/14/14, Trevor Perrin <[email protected]> wrote: >>> Anyone know what the best version of MQV is? (HMQV, FHMQV, CMQV, SMQV, >>> TMQV, >>> ??) >> >> I assume that anything with “MQV” in its name is patented, so I've >> only looked at the original MQV, and only cursorily (just enough to >> verify that ‘Ace’ doesn't look anything like MQV). >> >> My recommendations would be: >> >> * If you are willing to implement and use a signature scheme, have the >> server sign a (DH public key, time interval) certificate and send it. > > Time sync's another issue there.
Most security systems already require some time synchronization. >> * If you are willing to require that authentication public keys live >> in the same group as the forward-secrecy keypairs, and don't want to >> use signatures, consider ‘Ace’ (a variant of the 1986 ‘MTI/C0’ >> protocol described in the original MQV paper). (‘Ace’ can be modified >> to perform mutual authentication by replacing the client's X_1 >> ephemeral keypair with a long-term authentication keypair.) > > 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.) >> * If you don't want to use signatures and you don't want to do >> authentication in the same group as forward secrecy, use a >> straightforward DH authentication protocol (like e.g. ntor or what >> you've called ‘Triple-DH’). > > 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: * the system has two base points P_1 and P_2 in separate groups E_1 and E_2; * the server publishes long-term key B in E_1; * the client sends ephemeral keys X_1 in E_1 and X_2 in E_2; * the server sends ephemeral key Y in E_2; * the parties use H(X_1, X_2, B, Y, CDH(P_1, X_1, B), CDH(P_2, X_2, Y)) as the shared secret key. This has the slight drawback of requiring more ephemeral keypairs -- but any party which sends a nonce (to be included in the shared-secret hash) can re-use its ephemeral keypairs in multiple protocol runs. Robert Ransom _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
