Re: [Cfrg] revised requirements for new curves

[Adam Langley <[e-mail]>]

(I'm commenting with my Google hat on. I'm on vacation at the moment
and haven't circulated this around internally but I believe that this
reflects our position. Where I'm less sure I've used "I".)

> SE5. Required: each set of curve parameters should be generated by a
> well-defined procedure that allows only a limited and quantified amount of
> flexibility. If the selected procedure involves the choice of an initial
> seed, then the seed will be selected by multiple independent parties using
> a procedure having the property that no collusion of all but one or fewer
> of the parties can exert any control over the chosen seed. [RC]

Although flexibility should be eliminated where possible, we believe
that forgoing sensible optimisations because of a fear that someone
might know a magic attack on a subset of curves and might be guiding
the selection them that would be a mistake. We are not looking for a
replacement for P-256 because we seriously worry that the NSA
backdoored it. We're looking for a replacement because we think that
we can get something much faster and simpler.

Past a point, constraining the curve based on that fear isn't valuable to us.

> SE6. Required: the selected curves should provide levels of security that
> match to a good approximation 128-bit, 192-bit and 256-bit security
> levels, as these levels are currently commonly understood in the wider
> security community. [NC]

We don't want three curves. I'm not completely convinced that we even
want two, but two is plausible. For symmetric primitives, matching
powers of two makes sense because it fits well with software
implementation. For curves that motivation is much weaker.

Above the 120ish bit level one is no longer fighting stronger
attackers, but hedging against a breakthrough (but not too much of
one). Matching 192 or 256 bit security levels is a *misunderstanding*
in the wider community, and is thus of the lowest priority.

> IP2. Desired: securely, simply and efficiently implementable world-wide in
> a patent-free manner. [RC]

This is probably a requirement for us, unless the "royalty-free" was
legally strong, didn't include registration etc. I cannot specify
exactly what we would require in that case because it's not my area.

> IN2. Required: minimise work needed to generate suitable OBJECT
> IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC
> 5480 (PKIX). [C]

I don't think that I understand what this means, or rather, I can't
imagine how a curve could fail it. By having a name so long that it
caused tooling problems perhaps?

> IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS,
> SSH, IKE, IKEv2, Kerberos PKINIT. [RC]

The cost of making a change in these systems is largely fixed. I think
that trading off too much to make the change smaller is often a false
economy. If the thinking here was to try and reuse ECDSA with new
curves for reasons of easy of patching then I think that would be an
example of such a false economy.


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org