[curves] MQV

[Robert Ransom]

On 5/14/14, Trevor Perrin <trevp at trevp.net> wrote:
> On Wed, May 14, 2014 at 2:38 PM, Robert Ransom <rransom.8774 at gmail.com>
> wrote:
>> On 5/14/14, Trevor Perrin <trevp at trevp.net> 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