On Thu, Jul 10, 2014 at 7:57 PM, Brian Smith <br...@briansmith.org> wrote: > On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx <k...@roeckx.be> wrote: >> >> [snip] >> An other alternative is using curve25519. It's also not standardized yet, >> but at this time it seems more likely to be standardized first. > > Thanks for bringing up curve25519. I'd like to share a recent paper > written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja > Lange: > > "Curve41417: Karatsuba revisited.'' > http://cr.yp.to/papers.html#curve41417 > > Section 1.5, "Is high security useful?" is particularly interesting.
It seems plausible that there could be advances in attacks that cause incremental improvents in attack capability without being such breakthroughs as to make ECC totally fall, so in that sense the notion of aiming for as much computation as a performance budget allows for is persuasive. However, I observe that https://www.imperialviolet.org/2014/05/25/strengthmatching.html seems to argue against adding extra security in the hope that future advances make the margin useful but don't go all the way past the margin. > I would like to hear what others think about this, including what > people think Gecko should do. The idea of not adding Curve25519 support in order to wait for something that's presumed to be even better but that doesn't have the momentum of Curve25519 seems problematic. Curve25519 now has the sort of mometum that it looks like the best bet to get an interoperable alternative to the NIST curves. It seems to me that going for anything else will lead to a situation where some vendor tries to push Curve41417, another vendor pushes Goldilocks-448 and a third one pushes curves from Microsoft Research. And then everyone keeps using the NIST curves for interop. If indeed Curve41417 turns out at a later date to be the thing everyone should adopt, sure it'll be harder to get server admins to switch from Curve25519 to Curve41417 than to switch from NIST P-256 to Curve41417, but if NISH P-256 needs switching away from, it seems bad to push the switch further away out of fear that if admins get to switch to Curve25519 soon, they'll be less likely to switch away from that if Curve41417 becomes available also. Further, I think it would be good for Mozilla's software to be in the privacy leadership and now Cyanogenmod is leading over B2G by baking support for the TextSecure protocol in the system's SMS service. To get even to the point where a TextSecure-compatible SMS app replacement is available from the Marketplace (if not baked into the default Gaia SMS app), it would seem helpful to have Curve25519 as part of the Gecko platform and available via Web Crypto (once it has been specced how exactly Curve25519 should be exposed via Web Crypto if it is exposed). (The current Chrome-oriented JS implementation of the protocol uses NaCl for the Curve25519 part.) (All that with the disclaimer that I'm not competent to actually evaluate the cryptographic merit of the algorithms by looking at the math.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
