Depends on what you mean by “
the backdoor”.
That the generator is undetectably backdoorable through choice of constants has never been in question, from what I understand, and has been known outside the NSA (who designed it and chose the constants) via an explicit construction since before the relevant standard was finalized; it’s also so pointlessly slow nobody would normally include it in their own software except maybe out of completionism, which was ANSI’s official motivation for including it as well. (Green’s 2015 blog post[1] has the history and references.)
It’s also long been certain that Juniper included that generator in their software with the standard constant, then were hacked and afterwards for several years their software included in that place a different constant, with no other code changes, and finally an official emergency security update rolled that value back. The presence of the generator was not mentioned in the official documentation neither before nor after the hack, and the code gave the appearance of combining its output with that of another generator (which would have eliminated the backdoorability) while in fact not doing so because of something that looks like a logic bug. (I haven’t gathered the links on this but the surrounding comments here have most of them I think.)
Now, to me this seems like overhelming evidence that Juniper products have had a crippling security vulnerability due to the known backdoorability of Dual_EC_DRBG, without Juniper wanting it so. There is just no other plausible reason to break into Juniper and out of everything you could changing this one apparently pseudorandom string.
To make an argument against standardizing or using backdoorable cryptographic algorithms (Green’s point in the thread under discussion), this is as far as we need to get. The only thing the rest is relevant for is NSA’s reputation, government backdoors, and willing participation in them; but the Juniper story already suggests that the distinction between backdoorable and backdoored (and broken) is at best academic.
* * *
There is also a second place where Dual_EC_DRBG is known to be implemented, and that is the RSA BSAFE library. This library also includes but in most builds does not enable a weird TLS extension from what came to be known as the Extended Random family, though old and uninteresting Internet-connected devices have been spotted with it enabled. Now, the only thing this extension does—the thing it was described to be for by people bearing a US government badge who presented the Internet-Drafts on the IETF mailing lists—is expose more raw randomness from the system’s cryptographic random generator. No cryptographer anywhere has ever (publicly) described or even suggested any way to use this to improve the security of TLS in any configuration, including the authors of the Internet-Drafts. (See Green’s 2017 post[2] and links therein for the details.) However, if you are trying to break the system’s vulnerable random generator, exposing more of its output is immediately useful.
We are now two for two in commercial vendors of security products who implemented Dual_EC_DRBG also exposing its raw output (thus enabling the exploitation of the backdoor if one is configured through the choice of its constant) through ways that are both unusual and unnecessary for the operation of the product (logic bug for Juniper, completely useless and unused experimental TLS extension for RSA).
That when implementing Dual_EC_DRBG in the first place necessitates an explanation. Random generators are essential in a cryptographic systems, but unlike ciphers and such they are a completely opaque implementation detail—somebody you’re communicating with not only mustn’t depend on but actually can’t distinguish which generator you’re using (indeed a generator that can be distinguished is defined to be broken). Thus the choice of generator is a combination of speed (and it’s a speed-critical component) ease of implementation and confidence in the cryptograhy. Not only is the cryptograhy in Dual_EC_DRBG dodgy and known to be so—it’s a choice of 32 data bytes away from being completely and undetectably broken—it’s also hard to implement (elliptic curves in general are Hell on Earth, and while careful choices like in *25519 and *448 can mitigate that somewhat, Dual_EC_DRBG as standardized doesn’t have the necessary structure) and most importantly stupidly slow. It might make sense for ANSI (or, indeed, the NSA) to include it on the list in case it turns out 20 years later that the assumed-intractable problems underlying every other generator aren’t but elliptic curve logarithm still is (this was the official motivation), but as an implementor the one choice you’re going to omit absent an external reason is the generator which requires difficult mathematics and is also two orders of magnitude slower. Dual_EC_DRBG is not “suspicious” as a choice of random generator, it’s stupid.
This, I think, is enough to rule out any non-extraordinary hypotheses on why both Juniper and RSA included Dual_EC_DRBG in their products, and as extraordinary hypotheses go, “NSA paid them to, either directly or by imposing that condition in government contracts, because it did choose a constant enabling the backdoor for the generator it invented” is a pretty good one. It’s also corroborated by (otherwise questionable but plausible) reports of the NSA doing just that for Juniper (in the Yahoo Finance / Bloomberg report under discussion here) and RSA (quite some time ago[3], although it never rose above a rumour and RSA PR tried to run some damage control at the time). This also mostly discharges the questions as to why NSA would create and champion a known-backdoorable algorithm for the standard in the first place, all while dodging the constant choice question in the committee discussions (and even if they birthed this monster for some other reason, they could hardly have missed a freaking patent on the technique filed while standardization still was underway).
All in all, this looks like strong enough evidence to overcome the conspiracy-theoretic penalty and leave me reasonably certain the NSA really did both consciously put this into the standards and spend years pushing it into commercial products.
As to the question of the enemies of the US using this, I can offer two points:
- Cryptography is obscure, the infrastructural importance of computer systems is widely underestimated, and government (or corporate, or diplomatic, or any large organization’s) bureaucracy everywhere is pathologically incapable of staying on top of important details. Nobody ever got fired for buying Juniper firewalls or licensing RSA libraries; it’s the respectable, enterprisey thing to do. (Furthermore, not that many reputable companies make VPN appliances at all; for all we know Cisco weren’t any smarter.)
- National security, intelligence and counterintelligence, state security, secret police, however your place and time of birth call them, have been thoroughly rotten for as long as they have existed, maybe longer. The crossover Crusader / Big Data mentality, “surveil everyone and let God sort then out”, has always been the default. (As well as the old Soviet adage, “give me the man and I’ll find you the charge”, although in more civilized places one is hopefully forced to use blackmail and not the legal system.) There don’t need to be any real enemies of the US (or wherever) in the chosen direction as long as your salary or purpose in life depends on finding them; and, to be fair, it’s not as if the US doesn’t have plenty of enemies within or without.
And that’s a damn shame, because the problem of national security (to use modernity’s chosen term) is not imaginary; it’s just that the solution, even given sincere and well-meaning people as input, always comes out sick.
Finally, regarding suspicion and proof, I don’t really see the distinction you’re trying to make. If “strong suspicion” is to be understood as “weak but not negligible evidence one is struggling to formalize the reasoning for”, I disagree that’s what we have; if instead it means “strong but circumstantial evidence”, I agree, but the boundary between that and “proof” is largely nonexistent, especially in a situation such as this. Unless yet another good person self-immolates specifically to expose the nature of this particular trick in the NSA’s enormous bag, this as strong as support for this hypothesis is going to be, so demanding “proof” as opposed to the current “strong suspicion” seems epistemically counterproductive to me. There’s been enough fire for few enough results that I can’t in good conscience advocate anyone inflict more on themselves; this particular bit of trivia by itself also seems not worth giving up one’s life over.
(Snowden’s factual contribution to this specific story has been vague enough that it’s not particularly worth mentioning—something something working with and/or to compromise vendors, something something breaking “most encryption on the Internet”—except maybe for drawing people’s attention to the points above, all of which are from other and frequently earlier sources. “Lent credence” is right.)
* * *
What part of the “mess with Snowden” do you count as incompetence? The exfiltration approach he describes in his book does sound like run-of-the-mill incompetence if taken at face value, but that’s hardly the part that people were (and, I hope, still are) miffed about.
[1] https://blog.cryptographyengineering.com/2015/01/14/hopefull...
[2] https://blog.cryptographyengineering.com/2017/12/19/the-stra...
[3] https://www.cnet.com/tech/services-and-software/security-fir...