Re: [Cfrg] revised requirements for new curves

[Adam Langley <[e-mail]>]

On Wed, Sep 10, 2014 at 3:15 AM, Paterson, Kenny
<[e-mail]> wrote:
> Should we infer, then, that Google would prefer at most a single curve at
> each security level (rather than, say, two)?

I was suggesting that only one or two curves be approved in total.

Consider the current situation: in terms of having a good
implementation base, P-{256|384|521} are significantly above the rest.
Of those, P-256 is the workhorse. There is some use of P-384,
generally, from what I've seen, for long-lived ECDSA keys (with
dubious justification). P-521 is hugely less common than either of the
other two.

In order to get a performant, solidly constant-time implementation,
one needs, in practice, to hand craft the field operations for an
elliptic curve, which is quite a lot of work. That's been done for
P-256 in many cases, but much less so for P-384. (Since P-384 is
substantially used for ECDSA verification, constant-time is less of a
worry there.)

Diversity of curves dilutes the capacity for building, auditing and
verifying good implementations. Also, the precomputed tables for high
speed signing take too much space in some clients if there are several
of them, and then implementations need to support and test two build
modes: fast and small.

Many systems will never be able to drop support for P-256 and 384, so
these new curves can only add to the implementation burden. I think
that a single curve to replace P-256 can pay its way by being faster
and simpler. I'm much less sure about a second, and pretty confidently
against a third.


Cheers

AGL