[curves] MQV

[Trevor Perrin]

On Wed, May 14, 2014 at 1:50 PM, Michael Hamburg <mike at shiftleft.org> wrote:
> From a brief look, my guess would be SMQV, though FHMQV is also a possibility.
>
> I’m skeptical of the “NAXOS trick”;

+1

> it seems to me that it adds security in proof models, but not in the real world.  So no NAXOS or CMQV.  TMQV adds complexity and computation for what looks like mostly just a better security assumption, which doesn’t seem like a huge win to me, though maybe it’s worthwhile.

I.e. cryptographers are OK with Gap-DH assumption for common elliptic
curves, so it's not worth adding complexity / computation cost to
remove it?

>  The orthodox MQV protocols (HMQV, FHMQV, SMQV) all have about the same performance.  You might as well throw everything into the hash function, since that seems like it could conceivably be helpful, and costs almost no performance or complexity, so FHMQV and SMQV seem better than HMQV on those grounds.  Between the two, the SMQV guys argue that theirs is marginally better for side-channel resistance and for smart cards, and I don’t see a downside or a reason to doubt their arguments, so I’m guessing SMQV is the best option.
>
> I don’t know about the patents.  If there are patent concerns on one or the other, that probably outweighs these relatively minor differences.

The lineage seems to be (children indented more than their parents):

MQV
  HMQV
    FHMQV
      SMQV
    CMQV
    TMQV

I think Certicom's US filings were in 1995 so should expire in 2015,
which isn't that bad [1].

But IBM filed on HMQV, which I think doesn't expire till 2025 [2].

So the original MQV is perhaps the closest to being feasible.  Are the
enhancements in HMQV and successors that important?  I guess I should
read that paper...


Trevor

[1] http://lists.randombit.net/pipermail/cryptography/2014-January/006108.html
[2] http://www.google.com/patents/US7747865