Hopefully the last post I'll ever write on Dual EC DRBG | Hacker News Reader

Hopefully the last post I'll ever write on Dual EC DRBG

blog.cryptographyengineering.com

108 pointswglb26 comments

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).

I imagine it's still classified, meaning nobody could admit it if they wanted to.

Yup, http://www.spiegel.de/media/media-35546.pdf

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...

[1] http://vimeo.com/97891042 (jump to 57:53)

[2] Same video, jump to 30:14

Just watched the whole video. Thanks for linked it.

I just wrote a reponse to Dr. Wertheimer's letter looking some of the misleading statements[0].

[0]: http://ethanheilman.tumblr.com/post/108115952435/a-response-...

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 believe it was proved that a backdoor did exist- that there's a private key which can be used to backdoor it- but not that the NSA actually held that key. But, who else would? https://www.schneier.com/blog/archives/2007/11/the_strange_s...

A leak confirmed that the NSA paid RSA to use that particular algorithm in BSAFE. http://en.wikipedia.org/wiki/RSA_BSAFE#Dual_EC_DRBG_backdoor

"Believe". So not proof. There's a lot of that going around on this particular issue, and a subtle but important difference.

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.

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.

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.

"Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency." -http://www.propublica.org/article/the-nsas-secret-campaign-t...

And again - "appear to".

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?

[0] http://bits.blogs.nytimes.com/2013/09/10/government-announce... [1] https://projectbullrun.org/dual-ec/patent.html

Please don't hijack pinch-to-zoom gestures with javascript that loads random articles on your blog. (iOS mobilesafari). Thanks.

So right now, what are recommended public key, cyphers and hash functions for reasonable crypto safety? What about safe crypto pRNG's?

The ubuntu's gpg lists the following:

    Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224

Well definitely don't use MD5. And SHA1 and RIPEMD160 are too short to be considered fully collision resistant.

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.

This was some recent advice for SSH: https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

It was on discussed on HN, at the time noone pointed out anything glaring about the advice given.

That's a nice link, thanks. I like the writing style. Clear advice, with explanations, not too wordy.

Do you have a pointer to the HN discussion?

It was discussed here: https://news.ycombinator.com/item?id=8843994

Thanks for the links!

Re: PRNG

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.

GPG's defaults are designed around compatibility. Some older clients require IDEA. Today, There's really no reason to not be using AES or SHA => 256.

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"?

Reply on news.ycombinator.com