Re: [Cfrg] Chopping out curves

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.

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 <watsonbladd@gmail.com> wrote:

> On Thu, Jan 16, 2014 at 2:07 PM, Dan Harkins <dharkins@lounge.org> wrote:
>> 
>> On Thu, January 16, 2014 1:50 pm, Trevor Perrin wrote:
>>> On Thu, Jan 16, 2014 at 1:40 PM, Watson Ladd <watsonbladd@gmail.com>
>>> 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
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg