RSA warns developers not to use RSA products | Hacker News Reader

RSA warns developers not to use RSA products

blog.cryptographyengineering.com

132 pointspedro8469 comments

Hasn't tptacek posted "nothing to see here" regarding this issue on HN a half dozen times because "nobody uses it"? :)

This was actually going to be the first thing I posted when I read this link.

tptacek repeatedly assured everyone that this was absolutely not a big deal and meant nothing because nobody in their right mind uses the standard.

Except whoops, one of, if not the, largest players in the field. I'm sure he'll have a bunch of really great replies that manage to simultaneously say why this still isn't a big deal and passive-aggresively insult our knowledge of the situation. I look forward to reading what he has to say.

He's been trying to downplay the importance of the leaks since it first started, so what did you expect.

I don't understand his constant line in the sand on this issue (amongst other things). You basically illustrated exactly how he structures his arguments on this topic.

If I was smart enough to understand what this comment meant, I'd respond to it. Maybe you could clarify? I can't find a way to reconcile it with its parent comment in a way that gives me anything to discuss.

You seem to have already addressed it in another comment:

>Thanks for the link. I would have just gone on confirming my own biases without it.

This is incredibly evident in your comments on Dual_EC and sometimes happens on other comments as well. You draw a line in the sand and argue around it constantly, eventually bleeding into passive-aggressive attacks on the knowledge of others.

I find it valuable to hear from others outside of my industry (which is not crypto) who have no expertise in that field. They often have a fresh and agnostic look at something. Do you think all these comments slinging mud at you - however inaccurate they may be - were born from nothing?

How about this: why don't you tell me what you think my "line in the sand" is? I bet I don't have that line at all.

I have a different explanation for why I always seem to be at odds with people on NSA topics, but I'll wait to provide it.

>eventually bleeding into passive-aggressive attacks on the knowledge of others.

Thanks for proving my point.

> I have a different explanation for why I always seem to be at odds with people on NSA topics, but I'll wait to provide it.

I'm very interested in that actually. I'm often curious what shapes people's perspectives on these issues, particularly if it doesn't align with any obvious incentives. I always thought that you must have family in law enforcement or something, but I'd love to know the actual reason.

* NSA topics are heavy on computer security issues and legal issues.

* I'm professionally involved in computer security, like you, and have an an amateur interest in the law (I'm considering law school at some point).

* Message board nerds have a lot of weird, wrong beliefs about computer security and the law.

There is a political difference between me and HN: I'm not an anarcho-capitalist (that silly "world's smallest political test" thingy puts me dead center in "left liberal"). But politics have little to do with where I end up on the NSA threads; it's things like not understanding (or really, having even skimmed) NIST crypto standards, or not taking the time to understand what the 4th Amendment means. The things that get me into "trouble" here have more to do with taking the time to actually read primary sources than anything else.

We probably disagree about NSA a lot less than you think we do.

I have a different explanation for why I always seem to be at odds with people on NSA topics, but I'll wait to provide it.

I hate it when people do that. If you have a position on something, don't leave us all guessing, just state it!

tptacek repeatedly assured everyone that this was absolutely not a big deal and meant nothing because nobody in their right mind uses the standard.

He was right. Nobody in their right mind does use Dual_EC_DRBG.

From this episode I conclude that RSA Security LLC was not in their right mind.

To be fair, the insanity of anyone using it was never called into question. We agree it shouldn't be used. As we all know, science has yet to establish any correlation between sanity and what companies are actually doing in the real world for security.

Edit: Actually, I take that back. I have no problem believing that RSA Security are perfectly sane. Would we be completely shocked if the reason they chose a questionable default was due to coercion from the spooks? Only NSA has the keys, so it's a pretty safe backdoor.

You know, props to China, had to go through the work of owning RSA's seed server last year just to level the playing field. They get so derided in the media for doing that, but it seems unfair when the other team has a backdoor. Who is the real "Advanced Persistent Threat"?

I'll call into question the sanity of anyone using it.

The problems with it were known days after the standard was published.. meaning anyone who implemented was well aware of its problems.

Edit: actually, the first attack was in march 06 -- 3 months before the standard was published: http://www.math.ntnu.no/~kristiag/drafts/dual-ec-drbg-commen...

Sorry, that was worded incorrectly. I meant that we all agree it was insane to use it. The contention was over whether or not it was in use, not whether it is a good idea to use.

I should have said calling into question the insanity, will edit.

.. because nobody in their right mind uses the standard

Looks like that still stands according to the article we're supposed to be discussing here:

".. no sensible cryptographer would go near the thing"

I too clicked looking for the tptacek comments…

But I also expressed the view that no one would have used this. I guess it makes a lot more sense now: It seemed weird to put it in the standard, as no one was going to just use it. I'd been guessing that they hoped that it would be made an option and then they could do some negotiation attack to force it. I was missing a more obvious explanation: Someone was already willing to ship it, but they wanted the plausible denyability of it being a standard, because it looked too suspect otherwise.

You seem to be implying that anyone uses BSafe. Does anyone use it?

You mean like here [1] and here [2] and here [3]?

[1] http://www.pcworld.idg.com.au/article/129305/rsa_security_so...

[2] http://satchitssecurity.typepad.com/a_page_from_satchits_sec...

[3] http://www.tgc.com/dsstar/01/0724/103320.html

I'm surprised by this. We look at a lot of stuff. OpenSSL is far and away the most common crypto library we see. Commercial crypto libraries are way, way down the list, after "reimplemented all of elliptic curve by hand".

Thanks for the link. I would have just gone on confirming my own biases without it.

That, I think, is indicative of this community. I come across it a lot, and there are some insanely high profile, non-US organizations that rely on it. SAP being an example that I'm ok with mentioning.

At that point my personal conspiracy is suggesting that tptacek has become some form of alliance officer for hn outreach efforts.

To be fair to tptacek, he was far from the only crypto person saying that...and for good reason. In the absolute best case the algorithm was known to at least be slow and complex to implement, two things that don't usually lead to widespread adoption. The news that RSA had it as the default is interesting regardless.

>> So why would RSA pick Dual_EC as the default? You got me. Not only is Dual_EC hilariously slow

Because the NSA didn't just backdoor the Dual_EC standard. It backdoored the technology industry, as well as the rule of law.

The RSA CTO's answers are hilarious. He can't really be that clueless as the CTO of a security firm, can he?

That would be incredibly embarrassing in itself (which it already is), but the alternative is even worse (choosing the one with the backdoor on purpose).

Especially the part about KDFs being deliberately slow, and according to him that somehow implies that RNGs should also be slow. Whut? This guy is really a CTO?

"The length of time that Dual_EC_DRBG takes can be seen as a virtue: it also slows down an attacker trying to guess the seed."

If a system's seed is weak, one attack is to try all likely seeds, run them through the PRNG to generate keys, and see if any of the keys work. A slow PRNG indeed slows down this process.

For instance, it would have slowed down the attack on the Taiwan Cryptocards, which exploited patterns in the seed that appear directly in the key, reported here: http://smartfacts.cr.yp.to/smartfacts-20130916.pdf

That's a really poor idea. If you're concerned about guessing attacks on your RNG seed, the right response is to increase the size of your seed -- NOT to slow down the function. To put it another way, adding one bit to the seed length is equivalent to doubling the cost of the attack. In other words, a 1000x slowdown in the generator is the same as about 10 bits of additional seed material. Not worth it!

No, it wouldn't have slowed the attack on the Taiwan Cryptocards one bit. That and the related "Mining Your P's and Q's" research involved deriving the private keys from the public keys using bulk factorization.

They did not need to simulate the operation of the poorly-seeded PRNG that generated them.

They got the first 103 keys with batch GCD. After that, they found many more keys by looking at patterns in the keys and doing trial division by keys that were similar to the patterns. A better PRNG would make that harder (to reverse-engineer the patterns in the seed) and a slower PRNG makes it slower.

A better (i.e., not completely utterly horribly broken) PRNG would have made it impossible to observe and associate patterns in the output, even with poorly seeded entropy. There's no reason such a PRNG needs to be any slower than a fast cipher or hash function such as AES or SHA-2.

I've been a big advocate of things like PBKDF2 and such to slow things down where appropriate. But except for very specialized circumstances (and an RNG isn't one of them), we want cryptographic operations to be fast. In general, we want RNGs (and most things) to be fast and efficient.

And in particular, TW Cryptocards analysis never had to run the RNG. Just had to look at 2 million public keys already out there.

His answers are post-hoc justifications. The real reason they picked it was because they wanted to make money on sweet, sweet government contracts, and the easiest way to do that is to just do everything NIST says to the letter.

http://lists.randombit.net/pipermail/cryptography/2013-Septe...

You're assuming that the CTO is technically competent. I've found over the years that even CTO's who once were technically competent either get lobotomy's, or suffer from hypoxia from the low oxygen at the summit of major corps.

Or, management exists cover up bad hiring practices. Take your pick. Either way, CTO's saying dumb things seems to be normal.

I think it's probably very easy to rise into the upper levels of management at EMC while being a complete moron.

We still don't know who at RSA opened the spreadsheet that carried the malware behind the SecurID breach.

Seems like we've got a reasonable guess now though.

He's in a tricky position. Imagine somebody in RSA taking decision years ago to follow "strong suggestion" of NSA, accompanied by millions of dollars, to choose certain algorithm as the default. Now current CTO has a choice:

1. say "we deliberately built the backdoor into our software, please never buy our products again if you value your security" and go live the rest of his life in a Buddhist monastery in Tibet,

2. say some embarrassing BS which gives him a veil of plausible deniability while raising doubts of his personal competency, but who cares, he's a C-type, they don't have to know all the details, right?

Would you trust a computer security company who didn't hash the passwords of their users on their web site, and instead stored the plain text passwords encrypted in their database, with the keys to decrypt them on their server, because they claim that "Your data are encrypted on our server, if you request the password to be sent to you by email the system knows how to decrypt the information and it will send you the Email. This is for customer convenience as many customer do not wish their password to be reset each time they have a problem."

Would you trust a computer security company that when you reset your password on their web site, sent you a new password that was literally the same as your email address that you signed in with?

If this company sold closed source encryption software, would you trust that the software was competently written and did not have back doors, if the president of the company defended their actions of not hashing passwords, and of resetting passwords to their user's email addresses?

What if the president of that company had been prosecuted for computer crimes in the past, and had spend time in jail for it, because after he was first caught, he went right back to phone freaking again and got caught again?

Would you trust the president of the company, who is a convicted felon, who fraudulently made a lot of money by computer crime and got caught, but had most of the charges dropped and his sentence reduced, not to have made a deal with the government and promise to return their favor of giving him a more lenient sentence in exchange for certain favors in the future?

Can anyone guess who I'm referring to?

I'll give you some more hints:

His company came out with a "secure" voice encryption product, and then a previously unknown anonymous hacker reviewed the product and its competitors, and wrote a suspiciously positive review of it, claiming it was the only one he couldn't break. His company then published a press release trumpeting the favorable review, right before a big mobile security conference.

A suspicious security researcher baited the anonymous hacker to post on his blog, and it turned out he was using an ip addressed registered to the security company whose product he'd written a favorable review about.

When confronted with proof, the founder of the security company denied astroturfing, denied knowing the hacker, and implausibly claimed the anonymous hacker must have been using his company's anonymous browsing service.

The same security company founder who spent three years in jail for phone phreaking, because he was convicting of hacking and defrauding profit. The same security company who stores their user's passwords in unhashed unsalted plain text encrypted with a key on their server. The same security company who resets their user's passwords with their email address. The same security company whose founder claims that "many customer do not wish their password to be reset each time they have a problem" justifies not hashing passwords, and resetting passwords to "convenient" email addresses. The same security company whose founder refuses to change his "unconventional" security policies after being confronted with these facts, and instead makes ridiculous excuses for his incompetence, and continues to betray the trust of his customers even after he's been confronted with it.

Can you figure out who it is now?

It irks me that many people are calling this a backdoor. It's not. It's a vulnerability. You have to exploit it to get in.

How do you figure? The scandal around the NSA PRNG is indeed a backdoor, is it not?

Serious question: what's the difference? I would have followed the definition for backdoor since it relies on particular secret information relating P and Q that the NSA might have—but where should one draw the line between backdoors and vulnerabilities? Intent?

Repeating my comment:

An intentionally introduced vulnerability can be considered a backdoor, even if it's not a matter of saying "open sesame" to open the so-called backdoor.

So yes, it's pretty much a matter of intent.

Nerd's law: A commenter C declares that concepts X and Y are completely different. Because parent commenter P failed to make this point, P is intellectually inferior to C. Hence C > P for all X and Y.

It's a PRNG based on a trapdoor function where apparently the NSA has the key. With that key they can recover the RNG state from just a small amount of it.

Thats a backdoor by most descriptions. This isn't just a bug.

Snowden obviously has that key as well.

Haha what? Not only is there no way of knowing that, but it's not even relevant.

An intentionally introduced vulnerability can be considered a backdoor, even if it's not a matter of saying "open sesame" to open the so-called backdoor.

Yes. The magic, poorly-documented constants are the "public key" while the "private key" is known only to the construction's author.

I upvoted you, you make a good point.

It's a backdoor. The original paper describing the hole is (hopefully) entitled "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng"[0]. It's no longer a "possibility".

[0] http://rump2007.cr.yp.to/15-shumow.pdf

Uh, yes it is still a "possibility". Unless you have a source I missed, which is possible but please actually cite it, all we learned about Dual_EC from the NSA leak was that the algorithm was designed at NSA. Lots of crypto is designed at NSA; it isn't all presumed to backdoored.

reminds me of the State Science Institute

Reply on news.ycombinator.com