Thread by someone directly involved on why the ISO rejected NSA ciphers in the past (hint: they refused to justify design decisions, lied, and attacked the credibility of people who had put out actually-secure crypto):
> NSA interventions in cryptographic design have historically gone in the opposite direction[1].
I'm not sure I'd say that given that there are some other designs and things that have gone on[1][2]. Particularly the Dual EC debacle. They have a history of helping make suspect or down right compromised crypto if they think they can get away with it. That said it does look like they avoid doing it to anything that gets USA GOV approval for use internally but it's difficult to say to what level they would actually go to for getting a backdoor out into the world that would let them look at other secrets.
Something I still fail to grasp entirely: according to the Twitter feed discussed here previously [1] the NSA just wanted Dual EC "in there", even, if nobody would use it, but they could use it. (They would even allow the choice of alternative values for P and Q.) Was this relying on negotiating encryption methods while establishing connections? Or did this imply yet another attack?
I don't think it's really a conspiracy theory. Recall that before the Dual_EC affair, the reputation of the NSA was that they were a benevolent force that helped strengthen DES against differential cryptanalysis before it was publicly discovered. The Dual_EC affair marked a turning point where people started to seriously consider the possiblility that the NSA was a malevolent actor weakening primatives for their own benefit.
Also the problem with Dual_EC wasn't just the bad design, but that they had (reportedly) paid RSA corporation to use it.
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 same way Dual_EC_DRBG became a NIST standard, the NSA pulls the strings.
You can't expect a government department to provide robust security to the masses when the rest of the government is trying the prevent that exact situation.
At this point anything, cryptography related, coming from NIST should be considered compromised.
You're right though, I guess I didn't mean to say that NSA would give up on or would not want back doors into widely deployed crypto algorithms, but even with Dual_EC_DRBG the suspicions were widely known and discussed before it was a NIST standard (i.e. I guess you could say it was a conspiracy, but it wasn't really a secret conspiracy), and the standard was withdrawn in 2014.
There's an important difference between an opaque "trust us" recommendation where it's broadly impossible to verify the claim (e.g., Dual_EC_DRBG), and one such as this which is fairly anodyne and merely intended to put more weight behind getting people to move forward in their choice of implementation languages.
The NSA's split offensive/defensive responsibility is bad but that doesn't affect recommendations such as this.
Dual_EC_DRBG was a little different. It introduced an asymmetric key that only the NSA had the private key for. So only the NSA was able to exploit it. If they were to make stuff complex generically with the hope of it being buggy, it would lead to bugs that other intelligence agencies could exploit.
What type of confirmation do you want? The documents aren't going to be declassified in the next couple of decades, if ever.
I've never heard anyone claim that Dual_EC_DRBG is most likely not intentionally backdoored, but there's literally no way to confirm because of how its written. If we can't analyze intention from the code, we can look at the broader context for clues. The NSA spent an unusual amount of effort trying to push forward an algorithm that kept getting shot down because it was slower than similar algorithms with no additional benefits (the $10 million deal specified it as a requirement [1]). If you give the NSA the benefit of the doubt, they spent a lot of time and money to... intentionally slow down random number generation?!
As an American, I'd prefer a competent NSA than an incompetent NSA that spends my tax dollars to make technology worse for literally no benefit...
Wasn't this the whole situation with Dual_EC_DRBG? As far as I understand (which may not be that far when it comes to cryptography, admittedly), the NSA has already been caught intentionally weakening cryptographic standards via its influence over the NIST and by paying RSA.
RSA makes Dual_EC_DRBG the default CSPRNG in BSAFE. In 2013, Reuters reports this is a result of a secret $10 million deal with NSA.
According to the New York Times story, the NSA spends $250 million per year to insert backdoors in software and hardware as part of the Bullrun program.
> extensive documentation that the NSA is, in fact, surreptitiously introducing security holes in software?
I've seen speculation to that, but not "extensive documentation", at least from the perspective of simply breaking all hardware.
Buying descriptions of existing vulnerabilities is not "introducing" them. Nor is haranguing companies into leaving in known vulnerabilities (though that is bad enough).
Even things like asking companies to use Dual EC DRBG is not "introducing security holes" in the way we understand it, as EC DRBG is actually secure against all adversaries except NSA.
Like, I'm re-reading the Guardian article now and it talks about the NSA "using supercomputers to brute-force encryption" as a strategy... hardly a jumping testament to the massive brokenness of the Web.
Going further to read the actual list of NSA practices helps confirm this a bit too.
For starters if you look at the description of their SIGINT Enabling Project it states that "To the consumer and other adversaries, however, the system security remains intact." (emphasis mine), which seems to be hinting at Dual EC DRBG (or at least, Snowden doesn't seem to have leaked any other NSA technologies that are broken only to NSA but resistant against other adversaries).
The one blurb I could find about deliberately introducing vulnerabilities had a very important caveat which everyone leaves out: "Insert vulnerability into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets" (again, emphasis mine). The Guardian somehow left that out of their description of that bullet, I'm sure it was just an oversight.
In other words this is not mass introduction of simple exploitable but a seeming formalization of the types of corporate-government partnerships that led to things like the Siberian pipeline sabotage, to be used in specific targeted operations. Indeed the Guardian seems to confirm that in their description of the NSA Commercial Solutions Center.
Even Snowden has spoken up in support of the concept of targeted operations by U.S. intelligence agencies, so I'm not sure why this should be surprising; it's the kind of stuff we expect the U.S. to do to gear going to Iranian nuclear weapons facilities or Syrian C2 bunkers.
So even if we give the NSA credit for surreptitiously breaking crypto around the world, this particular method does not appear to match their style or even their own internally-held methods. It seems like the kind of thing NSA would take advantage of without revealing it, but not the kind of thing they'd intentionally add to a non-targeted iPhone. And, if they did add it, they'd add it to the flashed image, not the source, à la "Reflections on Trusting Trust".
Maybe. NSA wants algorithms to be secure against anyone but them. Perhaps this algorithm cannot contain something in the form of Dual EC_DRBG, where they're effectively handing out a public key as part of the algorithm and they have the private key. However, it could also be that there are particulars of the algorithm that make hardware that the NSA has and doesn't expect anyone else to be able to obtain, work especially well.
I had the same take on Dual EC prior to Snowden. The big revelation with Snowden wasn't NSA involvement in Dual EC, but rather that (1) NSA had intervened to get Dual EC defaulted-on in RSA's BSAFE library, which was in the late 1990s the commercial standard for public key crypto, and (2) that major vendors of networking equipment were --- in defiance of all reason --- using BSAFE rather than vetted open-source cryptography libraries.
DJB probably did invent the term "post-quantum cryptography". For whatever that's worth.
The NSA will never do that as it would be tipping their hand about whatever novel technique they reveal. In the past the NSA actually did provide some constants that went into DES and people were suspicious as the constants weren't randomly chosen. Later on it came out that differential cryptanalysis would have broken the original constants but the NSA provided ones were chosen to thwart this. They clearly knew about it well ahead of it being discovered in academia. Then you have the NSA's shady dealings around Dual_EC_DRBG where there was speculation that this might be similar to when the NSA secured DES against publicly unknown advanced cryptanalytic attacks. Of course for Dual_EC_DRBG that wasn't the case, it was a malicious backdoor, nothing more.
The question comes down to "Is this a repeat of DES or Dual_EC_DRBG?" and the NSA has poisoned the well with their previous attack on cryptography standards.
The NSA is dual purpose. Both as a signals spy agency and a signals counterintelligence agency.
And ultimately, what's the difference between a publicly vetted algorithm proposed by the NSA and a publicly vetted algorithm proposed by someone else?
Everyone points at the Dual EC fiasco, but if vulnerabilities are possible either way it seems like throwing the baby out with the bathwater.
Right except on the other hand, look at the whole Dual_EC_DRBG fiasco where the NSA gave instructions for how one could pick parameters, but also offered their own suggestion (in some standards, one had to use the suggested parameters.)
The bit about choosing parameters suggests that the NSA didn’t have a benevolent reason to choose those parameters, and the evidence of that algorithm being exploited in the wild suggests that the NSA may have chosen their parameters with that exploit in mind.
As linked elsewhere in this thread, https://en.wikipedia.org/wiki/Dual_EC_DRBG
reply