Re: [Cfrg] A draft merging rpgecc and thecurve25519function.

[Brian Smith <[e-mail]>]

Adam Langley <[e-mail]> wrote:
> I've created an outline for what currently appears (to me) to
> be the only way that we might reach agreement.

As far as Curve25519 is concerned, whether or not agreement is reached
within CFRG seems to not matter any more, because Curve25519 is
already clearly the choice at the 128-bit security level, and it is
also now the default choice if no agreement is reached. It's already
implemented and documented elsewhere so no new CFRG document is even
really needed for it, though it would be nice to have one.

It isn't clear that it is best to restrict the choices in the stronger
security levels to the generation procedure in this document. More
importantly, that isn't something that needs to be decided before
everybody can move forward with Curve25519.

There are a lot of people that don't care much about the curves
stronger than Curve25519 and who don't intend to implement them. The
problem with your suggested approach is that all these people are
likely to join in support of this document in order to ensure
Curve25519 move forward, causing the people that *do* care about the
higher-security curves to get steamrolled, even if they have a
stronger case. In other words, politics would trump technical
arguments. That's bad.

Consequently, CFRG should wrap up the process for Curve25519, and
separately decide what to do at the higher security levels. This would
more likely ensure that the better technical choices are made at the
higher security levels. This makes sense because the urgency for
Curve25519 is notably higher than the urgency for the other security
levels.

It does seem reasonable to say that, before a curve that doesn't
result from the generation procedures is chosen at a higher security
level, there should be a clear, strong justification for that choice.
But, I don't think we should exclude the possibility of such a strong
justification existing for some curve(s). Further, I don't think we
should exclude the possibility of the generation procedure being
tweaked again, like when it was tweaked to make Curve25519 fit.

Cheers,
Brian