[curves] CFRG's 25519 proposal

[David Gil]

Absolutely no disagreement. The proposal is an utter disaster.


And an excellent illustration that consensus by committee is a terrible way to specify crypto.

I am of the view that it is long past time to dismiss the (modern) IETF model as a failure. The IETF process has produced a succession of specifications that have either (1) failed to be actually used, (2) failed to be secure, or (3) both.

It is no longer "working code and rough consensus". It has become an ISO-a-like.

- dlg


On Thursday, November 27, 2014 6:41 AM, Trevor Perrin <trevp at trevp.net> wrote:


So the latest "new curves" idea from IETF's CFRG (which is considering
curves to recommend for TLS) is to use the 25519 field prime with a
minor tweak to a different "A" value.

http://www.ietf.org/mail-archive/web/cfrg/current/msg05600.html

Of course, this breaks compatibility with existing 25519 uses: Tor,
iOS,OpenSSH, GnuPG, TextSecure, WhatsApp, NaCl and its many users:
(Pond, Threema, CryptoCat, CurveZMQ), and so on.

I imagine most of these projects won't change.  (I work on TextSecure,
and we won't replace keys and code for a meaningless tweak like this).
So this would fragment the 25519 landscape into 2 curves, both of
which require support indefinitely.

It's hard for me to understand this proposal.  My guess is Microsoft
has invested a bunch of time in proposing new curves and is insistent
that they get to put some stamp on the result. And I guess Google's
gotten tired of IETF's curve dithering, and only cares about TLS, so
is willing to concede.

But given the larger context of 25519 adoption, which includes a lot
more protocols than just TLS, and where DJB's existing 25519 curve has
significant traction, this seems like a terrible idea.

Anyone disagree?


Trevor
_______________________________________________
Curves mailing list
Curves at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/curves