Re: [Cfrg] Fwd: Re: Safecurves draft

[Manuel Pégourié-Gonnard <[e-mail]>]

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.

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.

>> - no indication of security concerns and need or lack of checking
>> public key values
> 
> Important advantages. We should cover this, I think.
> 
While at it, we should also document the requirements for private keys, which
are different from the way they are usually chosen for short Weierstrass curves.

>> […several objections to the name ‘safe’, implying other curves
>> aren’t, raising the NIST curves…]
> 
> As the SafeCurves criteria clearly explains:
> [...]
> 
I think this kind of thing should go in the draft :)

> Compared to the curves we've got at the moment (most of which don't
> even have clearly-explained design criteria, and the ones that do are
> unfortunately inefficient), the choice of name seems entirely apt to me.
> 
I tend to disagree on this point. Don't take me wrong, I think these curves are
a useful tool in making security better, for all of the reasons mentioned above.
However, they're not some kind of magic security pill either, and IMO it would
be bad for security to give this impression. This goes both sides:
- people shouldn't think any implementation of the "safe" Montgomery/Edwards
curves is automatically flawless;
- people shouldn't think the NIST/Brainpool curves are so impossibly hard to
implement right that they don't even try.

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.

Point 3 and 4 are entirely a property of the implementation, not of the curve.
Point 2 can (and must) be addressed by telling everyone to validate points. I
mean, the idea of validating inputs shouldn't be new to anyone implementing
crypto! About point 1, it probably depends on the reference used, but Hankerson
& al's "Guide to ECC", which looks like a classic to me, gives formulas that are
correct in all cases (but have data-dependant branches). Besides, this problem
can be completely avoided by using a well-chosen multiplication algorithm,
ensuring that the special cases will never be hit.

Overall, of course it's nice that issues 1 and 2 are completely annihilated by
Montgomery and Edwards curves, and to be fair point 4 is a bit easier to address
with these curves too. But I wouldn't go as far as to say that they are
inherently safer than the Brainpool curves. They are easier to implement
correctly, have excellent performance, and reduce the conflicts between security
and efficiency/ease of implementation, which is great. But I'm still a bit
uncomfortable with calling them "safe" and implying all other curves aren't.

Manuel.

PS: besides, there's a practical advantage in being more specific than "safe":
when/if someone comes with other curves which have arguably nicer
security/implementation properties, a neutral and specific term will remain
appropriate, while "safe" will sound odd. (It's like calling things "modern".)