The elliptic curve standard that was potentially undermined by the NSA is the Dual Elliptic Curve Deterministic Random Bit Generator ("Dual_EC_DRBG"). The weakness is specifically related to the design of Dual_EC_DRBG, and elliptic curve Diffie-Hellman is not affected by that problem. ECDH can be used with a variety of parameters. The nistp256 parameters currently used in TLS were generated by NIST and NSA in the late 1990s; there are no known insecurities in nistp256, but the generation method is not fully documented, so the IETF is planning to move to alternative elliptic curve parameters, like Dan Bernstein's curve25519 or the Brainpool random curves or the new Microsoft FourQ curve. Regardless of the parameter choice, however, ECDH would be breakable by Shor's algorithm running on a quantum computer.

True, authentication still relies on existing certificate authorities. Authentication has to come from some pre-existing trust relationship, and CAs -- for all their problems -- do make the web work. In TLS in general, including our post-quantum work, you only have to trust the CA up to when you start your communication (they could impersonate the server to you). Assuming you actually did connect to the right server, then after the communication is done the CA is not able to read the encrypted data you sent or received. So yes, there's trust in a middleman, but only for a limited time. Hopefully orthogonal technologies, like Certificate Transparency and DANE, will reduce the reliance on CAs.

I'm one of the authors of the research that was discussed. Unfortunately, the MIT Technology Review article doesn't contain much detail. Here's a link to our research paper: https://eprint.iacr.org/2014/5....

The scheme uses a mathematical primitive called the "ring learning with errors (RLWE) problem". Rather than multiplying large prime numbers together like in RSA encryption or using points on a curve like in elliptic curve cryptography, here the mathematical operation is based on multiplying polynomials together, and then adding small random noise. An analog of this is solving systems of linear equations: if you took first year linear algebra, you might remember that if I give you a matrix A and a vector b, you can use Gaussian elimination (row reduction) to find a vector x such that Ax=b. But it turns out that if I add a small random noise vector e, and give you A and (Ax+e), it becomes much harder to find x. Our work is about actually using RLWE, seeing how to design a key exchange protocol that's suitable for use in SSL/TLS and then implementing and testing it. (Here are some slides from a recent talk I gave about the research, which try to explain the problem in more detail: http://files.douglas.stebila.c...)

RLWE isn't our invention -- we build on existing research by Regev, Peikert, and others, and RLWE has been studied for a few years now. RSA and elliptic curve cryptography can be broken by quantum computers because they have a certain periodic structure that can be easily detected by a quantum computer using a quantum algorithm invented by Shor. But RLWE, and several related problems, don't seem to be susceptible to Shor's algorithm, nor to any of the other quantum algorithms that give an exponential speedup over normal classical computers. No one in the research community today knows if RLWE is hard for quantum computers, but right now people accept it as a promising candidate, and it is being explored for a variety of uses. If after years of cryptanalytic research no one manages to break it, then it may achieve the corresponding levels of confidence that the research community has in the difficulty of currently accepted problems, like factoring or elliptic curve discrete log.

I'm one of the authors of the research that was described in the article. Here's a link to our research paper for more information: https://eprint.iacr.org/2014/5...

Canada did have a battle of independence against the British. It was a bar fight that lasted 20 minutes.

http://en.wikipedia.org/wiki/Battle_of_Montgomery's_Tavern

According to Ulf Möller there will be a patch made before the next release to isolate the ECC code in case of patent concerns. The ECC code can be included or excluded based on a configure flag like the present RC5 and IDEA algorithms which are still patented in various parts of the world.

Compile-time flags already exist to turn on and off ECC code in OpenSSL - they are OPENSSL_NO_EC, OPENSSL_NO_ECDH, and OPENSSL_NO_ECDSA. Additionally, there's a compile-time flag to turn on or off the code that is allegedly encumbered by Sun patents and a compile-time flag to turn off code that might be encumbered by another company's patents.

Furthermore, this is not new to OpenSSL nor to the crypto world in general. Lots of algorithms included in OpenSSL are covered by patents, RC5 and IDEA being prime examples. The OpenSSL license and most other open-source licenses only give you rights to copy and distribute the code, not necessarily to use it. Just as it was illegal to use RSA cryptography in the United States before Sept. 2000 without licensing it from RSA Security, so too is it illegal to use RC5 without licensing it. The OpenSSL license does not and cannot grant you those rights.

The Sun provision is there to grant users additional rights. As the previous poster indicates, it allows you to use any algorithm that Sun has a patent on in the context of OpenSSL and be free from threat of patent infringement lawsuit provided you don't sue Sun over a related issue.

Is it reasonable for Sun to ask you to not to sue them for code they gave away for free in return for not suing you? That's a business decision you make when you decide to use OpenSSL code.

Is it reasonable for Sun to say you can use the encumbered code in the context of OpenSSL but not in other contexts (like a hardware accelerator)? Under US law, they've got the right to do that. Whether you agree with patents or not is a different argument.