[curves] MQV

[Trevor Perrin]

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.

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.


>> 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...


Trevor