Re: [Cfrg] Chopping out curves

[Watson Ladd <[e-mail]>]

On Thu, Jan 16, 2014 at 2:07 PM, Dan Harkins <[e-mail]> wrote:
>
> 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.

So the question is which. I think curve25519 and Ed448-Goldilocks make
sense, together with an
isogenous curve for signatures since Montgomery curves are a bit odd
from that perspective. Does anyone see a need
for more security levels then that/are these choices terrible for
reasons we haven't appreciated?

>
>   Dan.
>
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin