[curves] MQV

[Robert Ransom]

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