Re: [Cfrg] Fwd: Re: Safecurves draft

[Robert Ransom <[e-mail]>]

On 1/9/14, Manuel Pégourié-Gonnard <[e-mail]> wrote:
> On 09/01/2014 09:12, Alyssa Rowan wrote:
>> On 08/01/2014 23:50, Watson Ladd wrote:
>>
>>> I don't want to rename curves because that induces consistency
>>> issues.
>>
>> Entirely accepted: I raised it merely as a question. People are
>> already beginning to adopt these curves of their own volition, so
>> changing the names of them could be confusing, yes.
>>
> About names, I'd really like the names to reflect the type of the curve
> (Montgomery or Edwards). This is already the case for other curve families,
> by
> the way. So, Mxxx and Exxx seem great to me. I'd even go so far as to rename
> Curve25519 as M255, but I'm sure there are good reasons to disagree on this
> point.

Remember that Curve25519's parameter is *not* minimal subject to the
constraint of twist security with minimal cofactors -- Dr. Bernstein
considered a slightly more subtle criterion regarding the group orders
too.  Keep that in mind if you try to establish a systematic name for
Curve25519.

> While at it, I also think the document should define the curves for each
> type in
> distinct sections. Overall, the goal is that it should be easy for other
> document to define the of just the Montgomery (or just the Edwards) curves
> for
> use in a protocol, and refer to the appropriate section of this draft.

I don't see the benefit of defining both a ‘safe’ Montgomery curve
(for the present definition of “safe”) and a ‘safe’ Edwards curve over
the same coordinate field -- every Edwards curve with minimal
parameter can be used efficiently with Montgomery's formulas.  (The
Montgomery-form parameter becomes the reciprocal of a small integer,
which can be handled as efficiently as a small integer itself.)

(For that matter, I would suggest replacing Curve25519 with the
twisted Edwards curve a=-1, d=121665 over the same field in any new
application or standard.)


I would also recommend highlighting the most efficient curves --
Curve25519 and Curve3617 have especially nice coordinate fields; even
2^521 - 1 is less convenient (the limb arrangement is less regular).


> Take the points list on the frontpage of the safecurves site, for instance
> (numbered by me for convenience).
>
> 1. Your implementation produces incorrect results for some rare curve
> points.
> 2. Your implementation leaks secret data when the input isn't a curve point.
> 3. Your implementation leaks secret data through branch timing.
> 4. Your implementation leaks secret data through cache timing.

> Overall, of course it's nice that issues 1 and 2 are completely annihilated
> by
> Montgomery and Edwards curves,

Issue 2 is obviated by twist security for single-scalar multiplication
of a Montgomery-form x coordinate.  It remains relevant for any
application which operates on full points (whether transmitted
uncompressed or compressed).

> and to be fair point 4 is a bit easier to
> address
> with these curves too.

Why 4?  The benefit of complete addition formulas is that
implementations don't need to switch to a doubling routine when two
points are equal.  Nothing about SafeCurves makes constant-time table
lookups any easier.


Robert Ransom