Are the NIST Standard Elliptic Curves Back-doored?
IamTheRealMike writes "In the wake of Bruce Schneier's statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected ... and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is 'Standards for Efficient Cryptography'), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a "verifiably random" process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general."
Sorry, I could have provided a link for that too. It was in the major Snowden story of last week that revealed the NSA was undermining public standards. The New York Times said this:
Although the NYT didn't explicitly name the bad standard, there's only one that fits the criteria given which is Dual_EC_DRBG.
The number field sieve relies on the smoothness of the integers modulo n. Using an elliptic curve group rather than the integers modulo n removes this smoothness, so the fastest algorithms available to determine the discrete logarithms are much slower (I believe they're based on Pollard's rho algorithm).
If that made no sense to you, go brush up on your number theory.
If you don't want to learn number theory, then accept that you are incapable of having an informed opinion on asymmetrical cryptography standards. (Which is okay, we can't all have an informed opinion on every issue; your brain can only hold so much stuff, right?)
Except that this came to light back in 2007. http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
I'm schizophrenic; no I'm not.
Suspicious yes, but not necessarily bad, remember that the NSA also manipulated the s-box values for DES to make them more resistant to differential cryptanalysis, a technique not yet known by the wider community.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
That story is about Dual_EC_DRBG which was indeed strongly suspected of being an NSA back door back in 2007. Snowden confirmed the suspicion. However this story is not about that algorithm. It's about the SEC random curves that are used for signing and other crypto, not random number generation. There are two different algorithms under discussion here.
Iranians are NOT semitic, they are Aryan, the name Iran literally means home of the Aryans. Named so because that is the one common thing that separates the various Iranian people from their semitic neighbours the Arabs.