Re: [Cfrg] Chopping out curves

[David McGrew <[e-mail]>]

Hi Michael, and Watson,

On 01/16/2014 05:53 PM, Michael Hamburg wrote:
> Hey Watson,
>
> Let’s maybe let this sit for a couple of days before declaring the matter settled.  I mean, as the author of Goldilocks, I’d love to see it become the one stronger curve that gets adopted.  But Trevor proposed chopping curves literally one hour ago, and Goldilocks has been on Safecurves for less than a week and isn’t even completely implemented.  I don’t want it to be railroaded into being the one curve in a new RFC, even if just for a couple git revisions.

I agree that people need more time to understand and think about the 
issues.  Let me suggest an approach:

- add a placeholder section to the draft stating that "This draft 
identifies one curve at each important security level, in order to 
promote interoperability.   These curves will be described in a future 
version of this draft.  Feedback should be directed to the authors and 
to [e-mail]."

- in the draft, outline the pros and cons for each curve type (this 
could be as simple as Michael's text in this email)

- collect feedback from reviewers and implementers during the lifetime 
of the draft

- before RFC publication, choose the curves and fill in the section.   
Leave all the text about the curves that were chosen, and move the text 
about the other curves either to an appendix or to the rationale.   Edit 
the rationale section so that it explains why the particular curves were 
chosen as mandatory-to-implement, and why the others were not.

This approach would make sure that the draft gets a broad review, which 
is really important, and it allows us to postpone making choices that 
might limit the solution space that gets considered. Our goal should be 
to create a well-considered RFC that provides value for the broadest 
possible community.

regards,

David

>
> Defense for why it’s a good curve, though:
> * Cofactor 4 is minimal for Edwards.  It could just as easily be a Montgomery curve; Ed vs Mont was mostly an arbitrary choice.
> * 448 is a round number (although this can hurt us in point encoding, depending on the options)
> * 448 is about the largest bitsize which can fit into a 16-limb reduced-radix multiplier on a 32-bit arch without carry problems.
> * 2^448-2^224-1 is Karatsuba multiplier friendly.
> * Solinas primes are fast.  Field mul comparable to about 2 muls over 2^255-19 on Intel.
>
> Downsides:
> * If you don’t like “special” primes, then you surely won’t like a Solinas trinomial prime.
> * If the point encoding is as spec’d, it’s one bit too long.
>
> Cheers,
> — Mike
>
>
>
> On Jan 16, 2014, at 2:36 PM, Watson Ladd <[e-mail]> wrote:
>
>> 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
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
> .
>