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 <[email protected]> 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 [email protected] https://moderncrypto.org/mailman/listinfo/curves _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
