Yes. RSA should lose customers because RSA didn't do their job properly -- they didn't select algorithms that were in their customers' best interest, despite all the facts being in the open.

> However, it is not a matter of debate that the RSA backdoor of BSAFE was and is not open merely to the NSA. It is an objective fact that anyone can take advantage of a backdoor like this.

This is not accurate. You need to know the private key for the generator, and this is not publicly known.

But, how many people have access to said private key? Will it ever be leaked, as some pieces of sensitive data have been? You can't trust keys that aren't yours to control, because while we can probably safely assume that NSA has better security than you or I or the companies we work for, it also has much higher capability attackers than most of us ever see in our lifetimes. The value of this particular private key is probably the highest of any known single private key in existence.

And, what about further down the road? 10 years, maybe 20, when this new type of key is predictably breakable with large enough resources? A 1024 bit RSA key is breakable for about $10 million today, according to a study that was linked to in a previous discussion about the state of quantum competing a couple days ago.

There are too many ways this one key could end up compromising potentially millions of locks.

" … because while we can probably safely assume that NSA has better security than you or I … "

This is the same NSA that has no idea what or how many documents Snowden exfiltrated as a contractor sysadmin?

Would you bet your company's confidential data (and possibly future existence) on the assertion that Snowden didn't have access to that private key? Or that other less politically motivated NSA contractors didn't have access to that private key, and which they could have sold for profit instead of publicly whisteblowing for ethical reasons?

I've seen no evidence that the key has been compromised, nor evidence that any important NSA keys have ever been compromised. I must assume they have different practices for their keys than for their data gathering practices.

While I've never seen it spelled out this way, I've always been under the assumption that the reason the NSA had so many outside contractors doing particularly dirty work was perhaps because they knew it was illegal and unconstitutional, and wanted it to happen outside the agency itself. But, I may be misinterpreting. It may have simply been a cost-cutting measure in which they failed to account for the lower level of loyalty to the state and higher level of loyalty to the constitution and individual rights than they were accustomed to from "company men".

> While I've never seen it spelled out this way, I've always been under the assumption that the reason the NSA had so many outside contractors doing particularly dirty work was perhaps because they knew it was illegal and unconstitutional, and wanted it to happen outside the agency itself.

It has nothing to do with "doing the dirty work" as the contractors are still working as agents of the government and are therefore held to the same limitations.

Rather there's a ton of seemingly-good reasons.

HR because you can't hire enough of the types of geniuses you need from the free market on government pay (it's hard, though not impossible, to justify paying a civil servant gobs and gobs of extra cash).

Additionally though there's the political reason: NSA can seem "smaller" by shifting headcount from government employees to contractors. It's not true, of course, but it doesn't have to be true for most of the people who would care.

Plus, it's just hard to scale government org. structure up and down as needed. Where you need to be flexible and the mission is not "inherently governmental" then turning to contractors is a popular way to adapt to changing situations.

But in no case are contractors held to more lax rules. In fact it's the opposite: they legally must comply with all restrictions on government action since they are (contractual) agents of the government, but they also have to comply with government ethics rules pertaining to the fact that they are not civil servants.

These rules are often annoying in their own right (e.g. a contractor is technically required to include the fact that they are a contractor and their company in any email signatures, must announce on the phone that they are a contractor and don't speak for the government, on and on).

In this post Snowden era, any time I hear the phrase "I must assume … ", I automatically have to wonder just how well founded that assumption is any more.

You're _probably_ right.

A year ago I would have said you were "probably right" if you told me the NSA wasn't recording metadata for almost every phone call, email, and website visit.

I don't disagree with you, really.

I think we both agree that any company that is willing to compromise its users to any entity, for money or otherwise, is not a company that should be entrusted with security. I will never deploy an RSA product, and will encourage my customers to choose other options (we support 2FA in our products, as of a couple of months ago, so we have the ability to determine what potentially millions of users choose, though realistically only a few hundred of our users have enabled 2FA, thus far; we don't support RSA).

So, yeah, it's also possible that the NSA's super secret input data they used for this RNG will be revealed or will be compromised by some powerful attacker (China, for instance, who would have very high incentive to compromise a large percentage of major corporations in the US in one fell swoop).

You're correct--I foolishly hadn't actually gone over how the Dual_EC_DRBG was broken until after writing this post. In general a broken random number generator breaks many parts of a cryptosystem, but the particular way in which Dual_EC_DRBG is broken only allows someone with a constant "key" which corresponds to the constants in the NIST standard to predict future generated numbers.

> vulnerable to any hacker who knows how to use the vulnerability

I must have missed this part of the news cycle. Can you explain how anyone other than the NSA can take advantage of Dual EC_DRBG? Did P and Q or whatever it was get leaked as well?

> Can you explain how anyone other than the NSA can take advantage of Dual EC_DRBG?

Dual EC_DRBG is a random number generator. If you use any random number generator long enough without re-seeding, it will eventually cycle (start producing the same sequence of bits again) and a discernable pattern will probably emerge long before that. If you can identify that pattern, then you can predict what will be generated.

To understand this: a really crappy random number generator simply takes the seed and increments it to produce the next random number, wrapping around to 0 when it hits 32 bits. So if I give you the numbers 56, 57, 58, produced by this generator, you can predict the number 59 will be generated next (and the number 55 was generated before). If these numbers were, say, the generated public exponent in an RSA public key, and the private key was generated just before, you could very easily figure out the factors used to generate the private key. Obviously nobody is using such an obvious "random" number generator.

In practice, most DRNG cycles are very large, and it takes many generation cycles for a pattern to emerge. This provides security because even if you get a few randomly generated bits, you won't be able to predict which bits were generated next. Even if you know the cycle, it would take many, many bits to be able to know where you are on the cycle and pick what would happen next.

Bruce Schneier explains much more authoritatively than I can[1] how Dual_EC_DRBG can be broken--that after collecting only 32 bytes of generated bits, you can predict what the generator will generate next.

HOWEVER, what I didn't know before re-reading Schneier's article, is that in order to predict future numbers from the previous 32 bytes, you need to know the proper constants (unknown) which correspond to the constants set forth in the NIST's Dual_EC_DRBG. So only the person generating those constants (in tandem with the unknown constant "key") can break the standard. So when I said that anyone can break the standard, I was wrong. Color me embarrassed.

[1] https://www.schneier.com/blog/archives/2007/11/the_strange_s...