Re: [Cfrg] New names for draft-ladd-safecurves

On Jan 21, 2014 10:30 AM, "Paul Lambert" <paul@marvell.com> wrote:
>
>
>
> On 1/21/14, 8:33 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
>
> >On Tue, Jan 21, 2014 at 7:28 AM, Bodo Moeller <bmoeller@acm.org> wrote:
> >> Jon Callas <jon@callas.org>:
> >>
> >>> I spent time talking to Dan and Tanja this weekend at ShmooCon about
> >>>this
> >>> sort of thing and I think that our agreement was that names like
"Curve
> >>> 255-19" (which covers both Curve25519 and Ed25519) or "Curve 414-17"
> >>>(for
> >>> the curve formerly known as Curve3617) made sense.
>
> Two names would be better to differentiate between a Edwards or Montgomery
> based point representation for the same curve.
>
> WE also are working on the assumption that there are just one curve choice
> for a particular field size. We should provide a extensible naming scheme
> that would allow the later introduction additional options (e.g. Ed255
> would be #1 of that size and flavor).
>
Why would we need these other options? If you have a new curve it needs to
look different to have a speed advantage. The security picture for ECC has
been stable for decades now.

> Paul
>
>
> >
> >My one concern which I've stated before is that we would then need a
> >single wire format for Curve25519 and Ed25519.
> >Robert Ransom's idea (sorry for the hijack) is the following: Suppose
> >Bv^2=u^3+Au^2+u is isogenous to ax^2+y^2=1+dx^2y^2, with the isogenies
> >u=(1+y)/(1-y), v=(1+y)/(1-y)x=ux. Then we represent points as u and
> >the sign of x.
> >
> >A=2(a+d)/(a-d)
> >B=4/(a-d).
> >
> >An implementation using the Montgomery ladder to multiply proceeds as
> >usual, using the fact that A is the reciprocal of a small integer
> >to rewrite the equations. It then reconstructs v (there is a fast
> >formula), and uses that to compute the sign of x. One using the
> >Edwards curves proceeds as usual, then inverts the isogeny to get u,
> >and uses x to get the sign bit.
> >The argument for this is we can specify all our curves in twisted
> >Edwards form with d small, a=+/-1, and life is nice for everyone.
> >Unfortunately Curve25519 doesn't fit this nice pattern, and people
> >want to use that exact curve. This form also involves a bit of extra
> >field math for everyone, even if they are all going to do ECDH or
> >Edwards addition afterwards, and so will want that form anyway. There
> >is also a problem of exceptional cases if a and d are nonsquares
> >modulo p for example.
> >
> >Have I rendered correctly the arguments for and against?
> >>
> >>
> >> Yes, it does. This would fix the single major flaw of Curve25519 --
> >> concatenating base-10 numbers to spell out a tuple just doesn't make
> >>sense
> >> (except as a trap, so that if anyone reads it out as "twenty-five
> >>thousand
> >> ..." you'll know they don't know what they're saying).  I also don't
> >>really
> >> like having whitespace in those names, so I'd prefer "Curve-255-19"
over
> >> "Curve 255-19".
> >>
> >> ("Curve" isn't very descriptive, but I've yet to see a more descriptive
> >>name
> >> for this curve that is actually helpful.)
> >
> >NIST isn't useful either as a prefix, but we live with it.
> >Anyway, my view is whatever people want to call these they can call
> >them, bobo and kiki aside.
> >>
> >> Bodo
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> Cfrg@irtf.org
> >> http://www.irtf.org/mailman/listinfo/cfrg
> >>
> >
> >
> >
> >--
> >"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
>