Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]

[Benjamin Black <[e-mail]>]

Several of the responses to this proposal leave me a bit confused as it
appears they were written without having read the draft. If your
perspective is that Curve25519 must be adopted, and under no circumstances
will alternatives be considered, then it will be difficult to reach an
accommodation. If instead you are interested in achieving consensus, the
first step should be understanding alternative viewpoints and considering
how we might find a middle ground. The draft documents such a middle ground.

The draft we (Microsoft, Google and NXP) posted describes rigid generation
of parameters for (twisted) Edwards curves. The generation process is about
as minimalist as can be for generation of secure curves. Additional rules
intended to produce a specific outcome are the definition of flexibility.
Constructing a curve explicitly for a specific implementation technique is
a short-sighted and contrary to good engineering process.

In addition, having a clear, rigid generation process for the parameters
allows those in need of curves for specific applications to easily and
deterministically produce them. Several people involved in hardware
implementation have expressed their concern with only producing curves
based on special primes. For such scenarios, a random prime selection
section could be added to the draft and the resulting curves need not find
their way into TLS at all. Again, being creative in accommodating the needs
of the participants is the key to consensus.

Recall that our preference was for similarly rigid generation of 3 mod 4
special primes. We still hold that preference, but we believe so strongly
in finding a middle ground acceptable on performance and security that we
have agreed to a process that does not produce most of the "NUMS" curves
and does not include our preferred prime at the 256-bit level. p = 2^255 -
19 with rigidly generated parameters is that performant and secure middle
ground.

The generated curve for p = 2^255 - 19 is not Curve25519 and is not
isogenous to the Montgomery curve in X25519. It is, however, not vulnerable
to the extremely minor concern that a private key is a multiple of the
group order. The isogenous minimum A Montgomery curve does have that
concern, and as has already been mentioned it is a trivial problem with a
trivial solution. Those working with signatures or ECDH with x,y points,
which are the majority of scenarios outside TLS ECDH via X-only point
format (and associated Montgomery isogeny), don't need to worry about it at
all.

As some have noted, this new curve can actually be faster than Curve25519.
Preliminary benchmarking of our implementation of it bears that out. It is
unfortunate that, having argued at great length for the primacy of
performance in selection, people are rejecting similar performance gains
because some code has already been deployed or multiplying by 8 instead of
4 represents a security threat.

We were expecting implementation considerations, such as requiring use of
compressed points for x,y and x-only for ECDH at the 128-bit security
level, to be addressed in another draft. That would decouple the generation
draft from the needs of a specific working group or scenario.

There is no perfect answer, there are only acceptable arrangements of trade
offs. To echo Adam, this is something we can live with to move forward.


b