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?
I suggest randomly selecting which random number generator you use to randomly select things.
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!
The problems with that random number generator were known from the start. It put EMC (RSA parent company) in an awkward position because the mistake was either stupid or deliberate. The management might not even know the answer because the NSA plants spies directly within companies to sabotage their products without management approval.
What does this say about other EMC products?
My advise on this is to never pretend to be stupider than you are. If it was deliberate, then it's better to own up and admit it was deliberate and promise to remove any other NSA backdoors. If it was stupid, then admit it and hire external auditors to help you find the other NSA backdoors.
Old expats from communist Russia love their new country.
Soviet USA, Soviet USA We love Soviet USA
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 ...
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.
The headline is horribly misleading. If you read the RSA communications, it's recommendations to use non-default PRNG where the default is now suspect. It's not about abandoning their own products.
"It's time to upgrade from our old stuff, which is buggy and slow." Microsoft does marketing like that all the time.
Shipping with config values that are dangerous if you start open source program before edits: the stupid user gets what they deserve!
Shipping with config values that are dangerous if you start closed source program before edits: OMG they're in league with $BAD_GUY.
Do you want to know why PRNG is the default standard in RSA's encryption product? Because US DOD and related companies that sell to and do business with DOD mandate following the encryption standards set by NIST, which is PRNG. I'd have to guess that the companies providing RSA with 90% of their revenue for this product are in that space and thus by making it the default they are serving their market. Meanwhile, blaming RSA for it being the default is as stupid as blaming other software vendors when the Sys Admins don't change the DEFAULT administrator password from 'admin'.
"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?
...lets get the facts straight so false rumors aren't perpetuated. RSA is NOT warning against stopping use of its products; the warning is about ensuring that the Dual EC DRBG RNG is not being used within their BSAFE crypto and DPM key mngt products.
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".