Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))
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
Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))
On Thu, Jul 10, 2014 at 09:57:56AM -0700, Brian Smith 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. I think it is likely the case that Curve25519 solves the wrong problem*: it tries to be faster than NIST P-256 but only the same strength, but I think a new standard curve should be the same speed as NIST P-256 but much stronger. My thinking is that now, when Curve25519 isn't an option, everybody is using P-256 without significant performance complaints. This shows that we don't really need something faster than P-256. Further, as the paper states in section 1.5, there are quite a few reasons to want to have a security level higher than ~125 bits, if we can get it with reasonable performance and without compromising other security goals, which we apparently can, according to this paper. By the way, an extra notable merit of this paper is that they focused on ARM performance I would like to hear what others think about this, including what people think Gecko should do. I think it looks promosing. But like the paper indicates it needs time for other people to review it before it's going to see any adoption. Curve25519 on the other hand is almost 10 years old now, and provides the security I currently think is at a good level, and is fast. So I think we should try to adopt curve25519 and later see if we should adopt Curve41417. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))
On Thu, Jul 10, 2014 at 7:35 PM, Kurt Roeckx k...@roeckx.be wrote: I would like to hear what others think about this, including what people think Gecko should do. I think it looks promosing. But like the paper indicates it needs time for other people to review it before it's going to see any adoption. Curve25519 on the other hand is almost 10 years old now, and provides the security I currently think is at a good level, and is fast. So I think we should try to adopt curve25519 and later see if we should adopt Curve41417. I mostly agree with Kurt; everyone is getting into curve25519 these days, and extra performance is always welcome. Maybe trying to leap over curve25519 is not a great idea if compatibility with everyone else is important. Cheers, Dirkjan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
