RSA: That NSA crypto-algorithm we put in our products? Stop using that Security biz RSA has reportedly warned its customers to stop using the default random-number generator in its encryption products - amid fears spooks can easily crack data secured by the algorithm. All encryption systems worth their salt require a source of virtually unpredictable random values to create strong cryptographic …
IMHO - he has, his "shoot down" email clearly show his pain at being trapped by US law (The land of the slaves that are forced to say they are free). Have a look at the various commented random.c files out there - make your one changes and compile the kernel with your version. We have all been forced to be on our own here.
The NSA must stop helping non US government sponsored hackers by weakening the security of there own systems. "Come on " do terrorists really use bsafe ?
And few even bother to ask anything that is not on the nightly news, every night?
Outside El Reg's (and other tech web sites) I doubt many in the US have a blind clue what's going on.
The believe the "We're keeping you safe from TERRORISTS (IE anyone outside America).
In reality the real enemy of the NSA is the US people.
It is obvious that the people who live in the US have forgotten that the Founding Fathers considered the government, any government, to be the enemy of the people.
That is why the welfare state is so insidious; it relies on a nation-wide implementation of the Stockholm Syndrome, which is pretty well universally effective.
"(The land of the slaves that are forced to say they are free)"
Erm, the slaves aren't forced to say that they are free, they're conned into thinking those chains ensure their freedom in the most Orwellian manner imaginable. Even to the point where many of the drones are utterly convinced that universal healthcare is harmful and unhealthy.
That's the rub with having a standard: You have to if you want to effectively communicate with others. Pick a non-standard or roll your own, and you might be able to communicate with the guy who created it... That's why broken standards are such a big problem and allowing government interference with them is so damn awful.
The NSA did not put the flaws there. The NSA championed a standards candidate and the standards governing body adopted it based on their public and peer reviewed processes. The NSA is not responsible for the decision making process of any standards bodies.
Or something very similar would be the answer if someone asked them.
NSA advice about cryptography surely is potentially problematic, and the results of accepting it or not are uncertain. I seem to recall that they critiqued and made specific suggestions to NIST about DES that had no known basis at the time but later were found to have strengthened the algorithm. The Dual_EC_DRBG initialization values the NSA recommended are obscure as to their origin. It is possible that NSA knows something about them that we do not, something that makes it easy for them to predict the PRG output and therefore to decrypt messages that used it. However, the pseudorandom generator appears to be flawed based on its biased output and should not be used for that reason alone.
http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html
Actually, that is close to how it works.
The NSA hires the most cryptographers and mathematicians in the world. Much of what they do is crypto, making it, breaking it, scrutinizing it.
When the NIST is looking at a standard, they go to the puzzle palace to find it, due to their specialist nature there.
The NSA meanwhile, determines what crypto the US DoD uses, which also meets with the NIST approved, NSA recommended crypto scheme.
It really helps with one is the only adviser to the regulatory agency.
"and which Intel won't let you see the details of ...."
Hasn't anyone tried to decap one of these Intel CPUs to find out for themselves what's in the works? I'd find it hard to think they'd create an implementation that would fool even a direct physical examination.
Actually you can, as it has to be stored somewhere for the CPU to implement. Microcode is like any other program. It has to be stored somewhere and then sent to the CPU to actually use. If it isn't already hardwired into the CPU (which you're saying it's not), then it has to be stored somewhere, and since we're talking an initial startup microcode, it's bound to be internal to the CPU since it can't rely on external inputs this early.
Quoth the Reg >> Other tactics include attempting to persuade technology companies to insert backdoors in their products, including it is claimed Microsoft's Outlook.com, and running so-called man-in-the-middle attacks to hoover up the world's online chatter and transactions.
Meanwhile, 15 years ago ..
The long, strong arm of the NSA (July 27, 1998)
http://edition.cnn.com/TECH/computing/9807/27/security.idg/
[…]
It's gotten to the point where no vendor hip to the NSA's power will even start building products without checking in with Fort Meade first. This includes even that supposed ruler of the software universe, Microsoft Corp. "It's inevitable that you design products with specific [encryption] algorithms and key lengths in mind," said Ira Rubenstein, Microsoft attorney and a top lieutenant to Bill Gates. By his own account, Rubenstein acts as a "filter" between the NSA and Microsoft's design teams in Redmond, Wash. "Any time that you're developing a new product, you will be working closely with the NSA," he noted.
[…]
Clearly wary of granting the government supervision over its products, Microsoft has stubbornly refused to submit a data-recovery plan, even though the Redmond giant already includes a data-recovery feature in its Exchange Server. "The Exchange Server can only be used when this feature is present," Rubenstein said. "Because we haven't filed a product plan, it's harder for us to export this than for companies that have filed plans."
[…]
Another interesting quote from the page you linked:
"The industry is facing a year-end deadline to add a government-approved back door into network gear. Vendors that don't provide this access risk losing export privileges."
Well, thanks to the NSA, IT American companies are going to 'lose their export privileges' anyway, 'cause no one in the rest of the world will trust American kit. I feel no pity for said companies, though, as they should have spoken up -and/or lobbied- against this shit a long time ago.
If that were true, wouldn't at least one company simply refuse to comply, and if threatened with the loss of export privileges, reply, "We lose either way; compliance means the world won't trust my company. So, given a lose-lose situation, I'd rather lose gracefully."
Like that email company did? I'm sure most people want to keep feeding their children. See the thing is that until the hype called Snowden, everyone thought you were bonkers when you talked of anything to do with the NSA. Those "everyone" people are the consumers that buy crap - including shitty software. USAian's patriotism leaks into places in non-USAian's minds that you would never think of. Psychology, er, media is a powerful tool.
Meanwhile, tin foil hats are the rage these days. It's a bit too late though. I wish you all the best. ;)
The leverage applied indirectly through caring for your family and employees is a major factor. As is that most companies big enough to be dealing with 'mandated back doors' are not going to be sole proprietorships, they're going to have a Board of Directors and quite likely shareholders as well. The Board or activist shareholders would be highly unlikely to allow the Executive staff from making decisions that threaten their export privileges.
Out of ~20,000 NSA employees over the decade plus all these newly disclosed programs have been going, only one was willing to break the silence. The other employees were most certainly not dealing with the life/death of hundreds of millions or more and they still didn't say anything. A company who is dealing with that kind of money is extremely unlikely to say anything.
I remember the big stink over NSAkey, back in the late NT4 and early W2K days.
It all got glossed over as "nothing".
Remember http://www.counterpane.com/crypto-gram-9909.html#NSAKeyinMicrosoftCryptoAPI
?
Mr Peabody: Sherman! Set the WayBack machine to when the NSA wasn't inside of everyone's crypto!
Sherman: OK, setting the WayBack machine to WWI!
(Old American cartoon)
If RSA knowingly published a weakened crypto system for 5 years and are only now admitting it - how many of their other libraries are compromised?
It's not like the NSA ceased being naughty in 2007.
Why would anyone continue to use any RSA product?
I know Microsoft and Goolge also cooperated - but it's impractical for a company to drop them. But the only point of buying security products from a company like RSA is trust - if you can't trust them then why buy it?
chief: great, so that encryption thing is all sorted?
spook: Yes sir, world+ dog are all convinced that all existing encryption is somehow flawed and are ready to switch to something better.
chief: and we have the better solution deployed?
spook: yes, we have been working with the security experts and university types for years. No one will ever suspect a ROT13 encoded message in the midst of all that gooblygook, and it passes all the decryption tests. It really is impossible to decrypt all the random garbage surrounding the actual messages.
chief: excellent, and how about that Snowden fellow, has he been taken care of?
spook: Of course, just like you wanted, a large payout from our secret account, a nice villa in nowhereistan, and a terribly tragic accident when he fades from the limelight.
chief: great news, and the best part of all is that all of the other countries are onboard with this they are all expressing their outrage and righteous indignation as planned.
spook: and the sheeple don't suspect the thing.
While von Neumann's well-known bon mot is still generally relevant in cryptography and elsewhere (and the rest of that piece - which deals with such issues as removing bias from random and pseudorandom bitstreams - should also be required reading for anyone concerned with these topics), it's utterly irrelevant to this story. Dual_EC_DRBG is not advertised as "producing random digits", and no one who understands it thinks it does so.
Indeed, the point of NIST 800-90 is to endorse PRNGs specifically to whiten entropy sources; in other words, its entire aim is to address von Neumann's point.
In any case, the news here isn't that Dual_EC_DRBG is weak. It's that RSA finally noticed, many years after everyone else did.
Now maybe the maintainers of OpenSSL will...
I always wondered why various products with certain encryption mechanisms weren't allowed to be exported. Especially when those mechanisms were already available outside the US. Makes more sense now. Those laws weren't really to stop exports. Rather just to force companies to comply with back door requirements.
"I always wondered why various products with certain encryption mechanisms weren't allowed to be exported."
I wondered why the DoD did an about face with Linux some years back.
Previously, it was forbidden. Utterly forbidden.
Then, one distro was approved. Only one. One ponders *how* that hat got red...
Ah SELinux, headache of sysadmins everywhere except the obsessive-compulsive micromanagers. At least it's slowly being bundled into wider policies, instead of relying on hundreds of individual manual program-to-file(/socket/etc) mappings every time you want to get something done.
Almost a perfect f**kup?
I'm completely baffled how anyone who had even minimal knowledge of what they were doing would choose this option if they'd done anykind of research or bench marking.
The $64m question. RSA management. Incompetent or pressured like any US company.
If you were a suit would you pick a solution from the world's most trusted supplier of security products. With the initials of the guys that invented public-key encryption (sort of).
Or would you trust your business to some communist free stuff off the internet written by hackers in Russia or Oregon or somewhere?
Which would you choose tomorrow?
"The $64m question. RSA management. Incompetent or pressured like any US company."
Both. I seem to recall RSA getting their root keys pilfered in a rather simply exploit. Had to rekey all of their clients.
Multiple incursions to their corporate network, "But nothing was compromised".
Of course, RSA only admitted the key compromise when it began to be exploited in the wild.
Corporate business as usual, with Six Sigma flair, as long as it's flat on its ass six sigma, erm, ultra-mega-uber-lean-and-mean-six-sigma, which bears little resemblance to the one that actually works.
Well, if you did, unknowingly, adopt a broken standard you could always blame it on the government... Not sure how well that would really wash with a Board or customers; but it's better answer than either:
a) We didn't know
or
b) We did know
It's one of the rare times you can trot out "the government did it through a vast conspiracy" and not come off nuttier than squirrel shit.
Well, if you did, unknowingly, adopt a broken standard you could always blame it on the government
The problem with that argument is that Dual_EC_DRBG is only one of four PRNGs endorsed by NIST 800-90. And weaknesses with it were announced within a year of publication.
RSA is claiming that they used Dual_EC_DRBG as the default because they hoped its algebraic structure would resist attacks that the non-algebraic constructions of the other three might be vulnerable to. That's a bit like saying you decided to walk to the shop rather than drive in case someone had planted a bomb in your car. Yes, it's a possible attack, but it implies a rather odd threat model.
It's also worth noting that NIST 800-90 lets you generate your own Q point, and doing so defeats the possible back door in Dual_EC_DBRC. It still has other flaws (notably speed and exposing too much state), but they're not fatal if you choose your own Q. RSA most certainly should have done so. So should the OpenSSL implementers.
(It'd be even better to reduce how much state Dual_ED_DRBC exposes - Shumow & Ferguson recommend outputting only half the si bits - but doing so probably violates conformance with the spec, and thus loses FIPS certification. FIPS certification is the main reason to use one of the 800-90 PRNGs in the first place.)
I learnt a new word today, "Kleptography". https://en.wikipedia.org/wiki/Kleptography
The 'RdRand' entry on Wikioedia also makes the good point that :-
"... It is impossible for software to tell whether this instruction is actually returning random numbers or whether it has been deliberately subverted, either by Intel, by a malware microcode patch, or by a virtual machine operating system ..."
So, malware might break even a legit Intel RdRand, and what are the chances VmWare implementations might be dodgy?
"So, malware might break even a legit Intel RdRand, and what are the chances VmWare implementations might be dodgy?"
I remember back when there were true random number generator cards. Expensive as hell. Some were even restricted in sales to government agencies.
Interestingly enough, they're still available. For around 1300 Euros.
As for VMWare, if the hardware is already dodgy in crypto generation, heaven knows what else was stuck in there as well, any implementation on said hardware would be potentially compromised.
"Interestingly enough, they're still available. For around 1300 Euros."
Most of those are high-performance cards meant to pour out megabits of entropy per second. You need that much entropy in a high-activity secure server (like an SSL trandaction server) to prevent the server getting blocked.
For lower-performance needs, other devices are available for a few hundred quid each. Some use USB, others PCI, still others 1x PCIe.
The cheapest prebuilt home solution, the Entropy Key, is now about as backordered as the Raspberry Pi was in its early days (BTW, the Pi's SoC has a HWRNG in it). So hacks are coming up with alternative ways to feed decent amounts of entropy to systems that may need it (like systems that do more than your average load of encrypted traffic). You can find plans that use webcams, sound cards (with or without radios plugged into them), even a smoke detector (the alpha particles from the Americium can be detected). They have their uses provided you whitewash the raw data first. I've been looking for a bodge-it-yourself solution that can use more reliable sources like avalance diodes or thermal noise, but the ones posted on the web are a bit beyond breadboard hacks. Oh well. For now, I'll settle for an old, cheap (read: noisy) webcam with the lens taped over (not this time, Big Brother).
All encryption systems worth their salt require a source of virtually unpredictable random values to create strong cryptographic keys and similar things
Rather overstated. While CPRNGs are important for many cryptographic protocols, they're certainly not required for everything. For example, a symmetric block cipher with a strong chaining mode doesn't need a "virtually unpredictable [pseudo-] random value" for its IV, and if the key schedule is any good, it doesn't need a CPRNG there either. (And the key schedule needn't behave like a CPRNG, so don't try that wheeze.)
That said, a backdoored CPRNG certainly does threaten the most commonly used cryptosystems, such as SSL/TLS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
