Re: [Cfrg] Chopping out curves

["Dan Harkins" <[e-mail]>]

On Thu, January 16, 2014 1:50 pm, Trevor Perrin wrote:
> On Thu, Jan 16, 2014 at 1:40 PM, Watson Ladd <[e-mail]>
> wrote:
>> Dear all,
>> Trevor Perrin suggests that we only put in Curve25519/T25519 and
>> E383/M382 so implementors can focus on 4 curves ala Suite B. Are there
>> any protocols in which larger curves would be useful? Anything we
>> might be missing with this decision?
>
> I didn't quite suggest that.
>
> I do feel there should be fewer curves.  Perhaps only curve25519 and
> (either Curve3617 or Ed448-Goldilocks).
>
> It takes a great deal of effort to do high-speed, const-time
> implementations of a different curve, so we should not diffuse that
> effort across too many choices.
>
> Note that Suite B only has 2 curves (P-256 and P-384).

  I think this is a good idea. Too much choice can lead to confusion
and lack of interoperability. When the brainpool curves were added
we pared it down from 14 (including twisted variants) to 4.

  Suite B has 2 curves because it defines two security levels. We can
define more security levels if needed but we should probably only
have 1 Chicago curve at each level.

  Dan.