Dual EC: A Standardized Back Door [pdf]
eprint.iacr.org
eprint.iacr.org
What I don't understand, is why the patent application was not objected in the secrecy order phase. Or was it secretly partly in the US, because the actual US patent apparently only covers the recommendation to pick your own P and Q, and not the actual mechanism itself. It is not clear to me what the last few sub-chapters are meant to show.
His claim was that the NSA had issues in the past getting encryption devices certified for use in unclassified environments because NSA controlled the certification process for classified encryption algorithms (which were themselves generally classified), but NIST controlled the certification for government use in unclassified settings (and these algorithms could not be classified). The NSA wanted to be able to use an existing algorithm in an unclassified setting. As the article does point out, Mr. George stated that the algorithm was intended primarily for their own internal use and user should be able to use any P and Q, though they needed their own P and Q certified for their own use.
Later on in the presentation he states that the P and Q were both non-deterministically generated random numbers. He states that the NSA has office devoted specifically to producing random numbers for their own use, and they just got the P and Q from there.
Whether or not you believe this claim is an entirely different and reasonable question (there's no real way to verify it), but why bother quoting him if you're going to selectively quote like this? If the P and Q are in fact purely random as Mr. George claims, Dual_EC goes from being a grand conspiracy to just a slow, crappy PRNG. I think selectively quoting to make this guy sound more sinister makes it look like the author wants it to be a grand conspiracy and just undermines the argument.
Btw., the entire presentation is worth watching if you have time - 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
Later
There was also a period during which the Red Hat Secure Server that shipped with Red Hat Professional linked against BSAFE. Its release timing doesn't square with Dual_EC though.
Extended-random was proposed as a way to allow DoD to deploy TLS on its networks, rather than using custom crypto protocols. OpaquePRF in particular was explicitly about getting TLS to play well with the Suite B policies. It was never recommended as a deployment default.
You have probably never used a crypto tool that used either Dual_EC or extended-random, for what it's worth.
Dual_EC was default PRNG in BSAFE-SSL-C for almost a decade. Shodan matched 1700 banners from this time, online now. The chance that a person interacted with a https service in that time is quite high I would think.
I'd be interested in finding out more about Red Hat Secure Server:
* It switched from OpenSSL to BSAFE-C in/around 2000
* RSA defaulted BSAFE to Dual_EC in 2004
* The last release I can see for Red Hat Secure Web Server is in 2003
* Red Hat Secure Web Server is EOL'd now.
A helpful Twitter points out this mailing list post from 2003:
http://blog.gmane.org/gmane.linux.redhat.security.server
... in which it's stated that Red Hat Secure Web Server had been EOL for some time.
It's looking more likely that those Shodan banners are not TLS implementations with Dual_EC defaults.
Thank for following this up. I think you are right. RH SWS was EOL before the Dual_EC default switch was made. If the only public banners for this product are from before this time, I will conceed that DUAL_EC likely never saw use on the Public Internet.
Pls unblock me on twitter ;-)
"Compatibility"? The excuse for the extension was detailed in TFA:
(Quoting the proposal:) "The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient.
(The article authors comment:) "Cryptographic parity" is not a common phrase among cryptographers. It is not defined in the document, and its intended meaning is highly unclear." But "Extended Random reduces the Dual EC attack cost from 2 ^ 31 to 2 ^ 15, since the attacker no longer needs to guess 16 extra missing bits."
The excuse actually sounds like "the bigger the number of bits you use, the more we need you to disclose publicly." Which was obviously true from the point of view of the attack.
What you're quoting from Bernstein's paper is the rationale DoD had for requiring a change to TLS for its deployment on their networks. This too was discussed on detail on the mailing list: their interpretation of the requirements of Suite B were that the randomness in a crypto transport had to be of arbitrary length, contributed both by client and server, and tied to keying.
Nobody at the time claimed that these were requirements for Internet cryptography. Just that DoD had these requirements internally, and it was better to define a TLS extension to meet them than to have DoD running some horrible custom protocol that the private sector would eventually have to implement too.
The "compatibility" I'm referring to is with DOD policy, not a technical measure.
I am not arguing that NSA was pure of heart in proposing OpaquePRF/extended-random. Perhaps they had a key escrow plan in place for their own networks? What I am saying is that there was no serious discussion that I can find for the deployment of OpaquePRF/extended-random on civilian networks.
Bernstein cavalierly mentions Rescorla in this paper, but never provides the additional color that Rescorla himself on the mailing list said he had no idea why the extension needed to exist, and did not understand its parameters.
Rescorla is an extremely sharp person. Do you think he thought, "I don't understand this extension, but NSA says it's important, so we'll all use it?" Of course he didn't.
It's obvious that DoD guys managed to add to the standard texts (most of the people reading would never know that it should be ignored, the text is there among all the other important texts) the mode in which enough output of the RNG will be part of the initial communication. The step 2, "now just implement it, here's the link" maybe hasn't occurred this time but it was almost a kind of backdoor entry to the standardization process. I can imagine that even if it wasn't really successful under your criteria, the DoD guy who managed to push it even that far could have been promoted. Or if somebody outside was involved with such a goal, could have received nice fees ("see, it's there, looks like the text of the standard, quacks like the text of the standard..."). Exactly like this discussion we have now: I can easily quote the text of that proposal (it's easy to Google it) and "it looks legit" (heh) but I have honestly no idea how I'd even find what was written in the relevant mailing lists at that time (or even more honestly, I know that I'd probably find it when spending more time than I'd like to spend, so I prefer just communicating, like most of the potential "targets"). For completeness, even if you already wrote what you consider important, I'd surely welcome your links to the relevant posts you mention.