Re: [Cfrg] Not the same thread -> was Re: Rerun: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd)

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Feb 25, 2015 at 12:58 PM, Mike Hamburg <[e-mail]> wrote:

>  Thanks, Paul.
>
> On 3.6GHz Haswell with OpenSSL 1.0.1f:
> RSA-2048: sign 1028us, verify 31us
> Ed448: sign 51us, verify 163us, dh 148us
> Ed480: sign 55us, verify 183us, dh 170us
> E-521: sign 79us, verify 256us, dh 241us
>

OK so ignoring the likelihood that we do an ephemeral in addition since
that is a good thing to do anyway and if the key agreement is designed
right, a WF-128 ephemeral only improves a WF-256 key.


For the server side

RSA2048: One decrypt, 1028 us
E-521: One DH agreement 241 us

So anything we do is a win on the server side. No need to consider the
other curves. EC is going to be faster. And that is before we consider
games like precalculation.


For the client side, if we have one intermediate and one EE cert:

RSA2040: One encrypt, two verifies, 93usec
EC 521: One DH, two verifies, 753 usec.

OK so performance is possibly an issue on the client. But only if we are on
a constrained device or the client is making a huge number of key
negotiations. And why would you want to do that on a constrained device.


Taking 448 as the baseline, 480 is 15% slower, 521 is 60% slower

Those figures might change a bit depending on optimization but I rather
doubt they will change greatly.


So on the one hand we have a measurable performance difference that makes
no real difference and on the other we have a measurable security
difference that makes no real difference.

Curve 521 does have the advantage of matching the work factor of AES 256.
It also has the advantage of squaring the work factor. The best
cryptanalytic technique we have to date is the meet in the middle attack
which reduces the work factor by the root, 2DES (112 bits) has the same
strength as DES (56 bits).


I don't care about the color of the bikeshed. What I care about is the
possibility that someone hates the color of ours so much that they insist
on building a new bike shed so that they can have their color. The Russian
requirement for P512 looked like it was an objection of that form till it
turned out that particular choice seems to have been made to exclude the US
proposal.

Tying back to the NIST discussion. If they really care about the color of
the bike shed, that is something I would personally consider very relevant.
Same for Microsoft or Google.


If P384 is the NIST baseline then I think it is easy to upsell them to 448.

If P521 is their established baseline then we could probably persuade them
to replace the P384 curve with ours but they are likely keeping their 521
curve.


>From time to time I attend meetings where it would be really easy to say to
someone with decision making ability that one of the best things that the
US Govt could do in the short term for cyber security would be to publish a
FIPS for the IETF curves. The problem being that the person who has
decision making authority has no idea what public key crypto is let alone
why they would want a particular curve.

If I push that button and the response that comes back up the chain is 'Our
521 curve is a billion billion times stronger', I doubt we get what we
want. If the response that comes back is 'we prefer Weinerschnitzel curves
with the double Irish option because they may have better security against
Schnorkelplage attack', it is rather more likely we get our way.