Comment by devx | Hacker News Reader

Comment by devx | Hacker News Reader

Is (NIST) P-256 secure enough? I might be wrong, but I think DJB is suggesting it's not, and that Curve25519 is preferable because it meets all the needed security requirements:

http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4...

And why just 128-bit AES? AES-256 is not much slower, is it? I think I read it's only 30 percent slower than 128-bit encryption. Either way PFS should become the default for all encrypted communications.

Companies need to start setting their own minimums years ahead of what NIST is recommending. NIST recommended the use of RSA 1024-bit until 2010, so that probably means companies should've moved away from RSA 1024-bit at least 3-5 years earlier. Yet here we are, with most companies today still using RSA 1024-bit 3 years after what even NIST recommended. Time to put security over profits first.

Also, as Ptacek is saying, it's time to implement TACK for certificate pinning:

https://twitter.com/tqbf/status/375742847485358081

Bernstein's big problems with the NIST curves are that they turn out to be difficult to write fast constant-time point multiplication for them (bear in mind that they were chosen before this was a well-known concern), and that they're easy to screw up in implementations. Those are real concerns, but so to would be fresh implementations of Curve25519 in all new software.

If one good thing comes of this most recent debacle, though, it'll be an industry reconsideration of the concepts that didn't manage to become NIST standards, like modern stream ciphers and faster curves.

The difficulties with fast constant-time point multiplication seem to be precisely the type problem the NSA might know of earlier. I.e. it's possible they contrived the standards to something they knew people could easily get wrong. Not a reason not to use them, just food for thought.

All the supported curves in TLS are most likely influenced by the US government (NIST, ANSI, and SECG). So we don't really have an option to use curves with a non-US provenance.

http://tools.ietf.org/html/rfc4492#appendix-A or list all openssl curves: $ openssl ecparam -list_curves

The NIST curves weren't influenced by the US government so much as they were defined by one NSA cryptographer, Jerry Solinas. On the other hand, the rationale behind their generation is pretty straightforward.

Reply on news.ycombinator.com