Slashdot Mirror
RSA Warns Developers Not To Use RSA Products
rroman writes "RSA has recommended developers not to use Dual_EC_DRBG random number generator (RNG), which has been known to be weak and slow since 2006. The funny thing is, that even though this has been known for so long, it is the default RNG in BSafe cryptographic toolkit, which is product of RSA."
Surely no-one in their right mind is still using crypto software from US companies? None of it can be trusted any more.
Is NSA finding this RNG hard to crack, or did NSA tell RSA to slip in a backdoor back in 2006 - and RSA folks are trying to crawl out of the hole they dug for themselves?
There's no point in pussy-footing around this. It's obvious that RSA was either forced or "rewarded" into using an insecure method. And that they knew it at the time (because they are cryptographers and because they don't live in the bottom of a well.)
Therefore, RSA has proven themselves untrustworthy at best, corrupt at worst, and quite likely both.
The question is what to do next? Rip out everything RSA in all infrastructure and replace it with something that works appears to be the best approach, but how should that be done and what should it be replaced with? And, most importantly, how can we verify that replacement?
If you're a zombie and you know it, bite your friend!
When it was discovered in 2007 that the NSA insisted on adding this PRNG to the standard, with constants they chose the general reaction was "so what? after all, this is one of many alternatives, and it is the slowest and least efficient". I assumed their idea was to somehow choose the PRNG in applications where they were one of the parties, but that seemed unlikely.
It's now clear what the idea was: secretly having companies use this PRNG. The original assumption was that companies voluntarily choose what products to put out, and that no-one would choose the obviously worst alternative. But if the NSA chould be the ones choosing ...
"stupid" is not in the picture. Making the slowest generator, and the one with doubtful security at the same time, the default is not stupid, it has to be deliberate. Now if the NSA people were any good at their business, they would have made sure that their compromised generator was the fastest, so as to give a plausible reason for making it the default. They failed event at this simple Deception-101 idea.
The more I hear, the more I think the NSA is a ham-handed, incompetent, slow and stupid bureaucracy that survives on sheer power to coerce others to do its bidding and on brute-forcing everything by spending incredible amounts of money.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Recall the NSA funding and internal standing in the US gov structure in the 1990's?
They had to deliver plain text 24/7 or face even less funding or other groups would have offered language contractors and bulk clearances.
The only trick was keeping the citation needed over generation.
Domestic spying is now "Benign Information Gathering"
or did NSA tell RSA to slip in a backdoor back in 2006
It's not so much the possibility that the NSA influenced RSA, rather they influenced the standard itself.
Here's the whole story according to Bruce Schneier:
http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
If you want news from today, you have to come back tomorrow.
There's the proverb about not attributing to maliciousness that which can be explained by stupidity.
VMware (also an EMC subsidiary) used an RSA implementation for their SSO product. It had a ton of problems and bugs, and each new patch release introduced more bugs. Applying pressure to RSA via EMC didn't help, so VMware ripped out the RSA implementation with a band new in-house implementation.
"I personally believed that it was some theoretical cryptographer's pet project," one cryptographer who asked not to be named told Ars.
He (or she) is not accusing anyone or suggesting anything. Why the desire to remain anonymous? I bet that many people active in cryptography even in academic circles are afraid. Indeed, chances are that active researchers are being monitored. You know, just in case.
Yet another reason that validates OpenBSD developers having spent years improving the quality of random number generation.
Say what you want about Theo, but their developers are top-notch and their stuff really works.
Was that mess posted with Android 2.3 by chance?
Hearts...
Bleed...
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
I checked it in a couple of different browsers. Only the Android browser made it look correct, and that was only on the second viewing using that browser.
When I first viewed it, it was broken in Android too. Most lines are repeated three times. For example, the sentence starting with "Here's the problem. Dual_EC_DRGB is flawed" is in there three times. I wonder what you'll see if I repost a copy / paste of the text:
Putting it bluntly, you can't.
Here's the problem. Dual_EC_DRGB is flawed, but is *required* to be implemented as part of anything that claims FIPS 140-2 compliance. Anything cryptographic you sell to the government is *required* to be FIPS 140-2 compliant, and operated in FIPS 140-2 compliant mode.
This includes just about all routers, switches, firewalls, operating systems and any other network or security gear in use by the U.S. gov't. Companies that supply this equipment include Cisco, HP, Dell, IBM, Juniper, EMC/RSA, Red Hat and others. In short -- everyone.
Granted, Dual_EC_DRGB is only one of four RNGs in the NIST suite, there is no way a user can specify *which* of those RNGs are actually used. Unlike setting cryptographic algorithms for SSL/TLS, there isn't any frontend for RNGs. They're implemented by the vendors. They're enabled in the products by a simple checkbox setting a registry entry (Windows), a kernel boot parameter (Red Hat) or config setting (most network infrastructure equipment).
Which is your vendor using? Who knows. But if we take the Snowden leaks seriously, the NSA has pressured many major companies to insert "weaknesses" or "backdoors" in various crypto-enabled gear.
Most people are thinking along the lines of "look for malicious code, odd errors or the like". But in the world of crypto, if the RNG isn't R, the entire thing collapsed like a house of cards. All tPutting it bluntly, you can't.
Here's the problem. Dual_EC_DRGB is flawed, but is *required* to be implemented as part of anything that claims FIPS 140-2 compliance. Anything cryptographic you sell to the government is *required* to be FIPS 140-2 compliant, and operated in FIPS 140-2 compliant mode.
This includes just about all routers, switches, firewalls, operating systems and any other network or security gear in use by the U.S. gov't. Companies that supply this equipment include Cisco, HP, Dell, IBM, Juniper, EMC/RSA, Red Hat and others. In short -- everyone.
Granted, Dual_EC_DRGB is only one of four RNGs in the NIST suite, there is no way a user can specify *which* of those RNGs are actually used. Unlike setting cryptographic algorithms for SSL/TLS, there isn't any frontend for RNGs. They're implemented by the vendors. They're enabled in the products by a simple checkbox setting a registry entry (Windows), a kernel boot parameter (Red Hat) or config setting (most network infrastructure equipment).
Which is your vendor using? Who knows. But if we take the Snowden leaks seriously, the NSA has pressured many major companies to insert "weaknesses" or "backdoors" in various crypto-enabled gear.
Most people are thinking along the lines of "look for malicious code, odd errors or the like". But in the world of crypto, if the RNG isn't R, the entire thing collapsed like a house of cards. All the NSA has to do is have essentially a single obfuscated line of code in the RNG. Something along the lines of "if Backdoor then RNG=Dual_EC_DRGB". Hell, in assembly it could probably be a simple JNE instruction.he NSA has to do is have essentially a single obfuscated line of code in the RNG. Something along the lines of "if Backdoor then RNG=Dual_EC_DRGB". Hell, in assembly it could probably be a simple JNE instruction.
The answer is don't use FIPS 140-2 mode, but if you're dealing with the government -- and a huge number Putting it bluntly, you can't.
Here's the problem. Dual_EC_DRGB is flawed, but is *required* to be implemented as part of anything that claims FIPS 140-2 compliance. Anything cryptographic you sell to the government is *required* to be
Interesting. It was posted in Firefox 24, as it was too long to try and do thru my phone browser (Android 4.2.2). But it looked fine in both. Interesting that you see it differently.
For the longest time I had issues viewing Slashdot in the Android browser. I'd get essentially an infinite loop of comments in a threat. That seems to have been fixed about a month or so ago.
What you copied back in your reply also looks properly formatted to me.
Learning HOW to think is more important than learning WHAT to think.
Why would the NSA deliberately weaken crypto algorithms ?
Sure, that makes spying easier but it is also quite dangerous. Because if the vulnerability is found anyone can access the encrypted data, including the enemies.
Think about it : the NSA releases a "recommended" crypto package. Obviously, US companies will be much more likely to use it than, say, the Chinese. If this package happens to be weak and that the Chinese find out, US companies will be the most affected. Also, to spy on its own citizen, it is more effective to use the legal system than relying on broken algorithms.
To use broken algorithms as a weapon, I think it is much more effective to distribute it undercover as something that is "definitely not from the USA".