The underlying letter http://www.ams.org//notices/201502/rnoti-p165.pdf carefully avoids saying whether or not the NSA put a backdoor into Dual EC DRBG. The language is several places seems to suggest it did not, but there is no outright denial (or acknowledgement).
In a keynote speech, Richard "Dickie" George, former technical director for the NSA Information Assurance Director, flat out denied it claiming that they were non-deterministically generated random numbers[1]. He also talked a little bit about how Dual EC became a public standard to begin with[2]. If you have the time, I think the whole video is worth a watch - he goes into the history of DES, espionage between the US and Soviets, getting cryptographic equipment working in tanks, etc...
Everyone keeps saying that the leaks confirmed the backdoor (e.g. wikipedia claims that) but which leak exactly? I didn't see a leak which confirmed the Dual EC DRBG backdoor. If someone did can you link it here?
PS - There may very well be a backdoor. In fact I believe that there is. But people keep claiming the Snowden leaks confirmed it, when I see no such confirmation.
I'm pretty sure most people have taken the certicom patent on using this technique for "escrow" as pretty strong evidence that it was an intentional backdoor.
Esp. coupled with its insanely slow performance and NSA's failure to point out that the selection of the 'random' numbers could be used to backdoor the cryptosystem. (especially when they continued to fail to point that out and support the cryptosystem while embargoing the patent for national security reasons).
But indeed, I'm not aware of any stronger proof. ... but people go to jail on evidence less circumstantial than this all the time. How high a bar must be set before we can just say "backdoored" without a page of footnotes?
I basically agree with your conclusion, but it sounds like they did not embargo the patent: https://projectbullrun.org/dual-ec/patent.html ("recommended against a secrecy order"). Or am I confused about the meaning? Anyway, it at least shows the NSA was institutionally aware of the possibility of backdooring, and other cryptographers knew about it, yet NSA pushed for its adoption.
Information security is all about probabilities and risk estimation and cost-benefit analysis, so I don't think people's concerns surrounding Dual EC DRBG are unfounded. That the constants are suspect (regardless who could potentially possess the underlying keying material) and that its performance is worse than similar algorithms is enough risk for many to rationally decide to abandon it---no conspiracy theories required. NSA probably (j/k!!) didn't engineer the POODLE attack into SSLv3, but that's not stopping people from abandoning the protocol (and rightly so)---it's just too unsafe. That said, the spectre of the NSA's involvement in this should concern both US nationals and our colleagues overseas, for political reasons as much as---if not more than---technical ones.
The confirmation of the backdoor comes from internal NSA memos that journalists with access to the Snowden documents have read. The source documents have not been made public to my knowledge.
They appear to? There's armies you could lose in the gaps of interpretation words like that allow.
'Appear to' covers everything from "NSA and DRBG mentioned in same document" to definitely not a statement like "the Dual EC-DRBG private key has not proven sufficiently useful in recovering useful intelligence and we're discontinuing the program" or some such.
> But internal memos leaked by a former N.S.A. contractor, Edward Snowden, suggest that the N.S.A. generated one of the random number generators used in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard — which contains a back door for the N.S.A. In publishing the standard, N.I.S.T. acknowledged “contributions” from N.S.A., but not primary authorship.
> Internal N.S.A. memos describe how the agency subsequently worked behind the scenes to push the same standard on the International Organization for Standardization. “The road to developing this standard was smooth once the journey began,” one memo noted. “However, beginning the journey was a challenge in finesse.”
> At the time, Canada’s Communications Security Establishment ran the standards process for the international organization, but classified documents describe how ultimately the N.S.A. seized control. “After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft,” the memo notes. “Eventually, N.S.A. became the sole editor.” [0]
Yes, it's somewhat circumstantial, but pretty damning. If they weren't backdooring it, I'd like to hear an alternate explanation for why the NSA has memos about, in their own words, "behind-the-scenes finessing" to "become the sole editor" and "rewrite" an international standard. All that hard work quietly manipulating things to be just how they want them and, oopsie, the standard just might have a back door! Meanwhile, as described in other comments here, they paid RSA Security to deploy the standard; and were made aware of the possibility of a backdoor[1], but for whatever reason continued recommending its use.
I'd entertain arguments that they were actually trying to strengthen it, as may have happened with DES, but in this case, they were pushing something that civilian contemporaries knew was dangerous. Malice or incompetence seem more likely than secret benevolence here. Or is there some other reasonable explanation I'm missing?
For starters, please refer to https://wiki.mozilla.org/Security/Server_Side_TLS. For SSH, I lack clear, good advice. I've tended to disable weaker ciphersuites using Mozilla's TLS configuration advice as a guide, and I've also tended to use larger key sizes than the defaults. As questionable as NIST's guidelines have been lately, I tend to follow the high end of their recommended key sizes, so 4096-byte public keys, etc.
Fortuna is built on top of an underlying block cipher in counter mode (typically AES), with some additional machinery for periodic reseeding to recover from the situation where the PRNG's internal state is compromised at a particular point in time.
But in most cases, the correct answer is to use your OS's /dev/urandom (CryptGenRandom on windows). If that is not secure your app is probably screwed whatever you do.
I'd be interested in hearing tptaceks response here, as he has claimed in his past comments that "no serious cryptographer" believes dual-EC-DRBG was backdoored. Is Matthew Green not a "serious cryptographer"?
