Hacker News Reader

Comment by danielweber | Hacker News Reader

I don't keep up on everything, but I thought Dual_EC_DRBG was used by nobody else for any real world crypto. Did these guys look over the Wiki page and decide it would be fun to be the first?

View on HN

To be clear, I'm describing problems with Moxie's hypothetical broken protocol, not with Telegram. Telegram does not (as far as I know) use Dual_EC_DRBG.

They aren't using it, but Dual_EC_DRBG is fairly widely used actually. There was a false meme denying that this was the case, but RSA and others proved that wrong.

Dual EC was not particularly common. Here's a metric: name a couple of products that you or I use regularly that ever used it.

It's not as if you could design a system with Dual EC instead of HMAC DRBG and not know it; Dual EC requires bignum math. It is incredibly slow for a CSPRNG.

This is disingenuous. RSA used it as a default in a commercial crypto library, as you must know. End users won't generally be aware that it's being used in a product, but that doesn't mean it isn't out there.

It is unlikely that most developers changed the default unless it was having a noticeable impact on performance, which wouldn't be the case if it was just used for key generation.

http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-al...

> In its advisory, RSA said that all versions of RSA BSAFE Toolkits, including all versions of Crypto-C ME, Micro Edition Suite, Crypto-J, Cert-J, SSL-J, Crypto-C, Cert-C, SSL-C were affected.

> In addition, all versions of RSA Data Protection Manager (DPM) server and clients were affected as well.

> “Every product that we as RSA make, if it has a crypto function, we may or may not ourselves have decided to use this algorithm,” said Sam Curry, chief technical officer for RSA Security. “So we’re also going to go through and make sure that we ourselves follow our own advice and aren’t using this algorithm.”

Here's someone who has dug up a decent amount of real-world products:

http://security.stackexchange.com/questions/43164/which-prod...

You probably don't use any product that uses BSAFE.

For whatever it's worth, for people who think this point is all part of some elaborate edifice of sticking up for NSA: I am now 99.9% convinced that Dual EC is in fact a backdoor, and while it's clumsy in a tradecraft sense (you can just look at it and see the problem), I've heard compelling scenarios in which it would have been effective.

I just don't think it's a backdoor that's relevant to modern software, or, even for its time (the early 00's), software that was in popular use.

What do you make of the list given in this other comment that includes copy machines and game consoles?

https://news.ycombinator.com/item?id=6940993

Dual_EC_DRBG is used:

http://security.stackexchange.com/questions/43164/which-prod...

> Since we know the RSA BSAFE library uses Dual_EC_DRBG (...) by default, I would guess that this would be the main vector.

> As for the use of BSAFE, I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices: surprisingly many printer/copier/fax devices use BSAFE, though for unknown purposes. Including Ricoh, Minolta, Océ/Canon, Brother, Fuji/Xerox, Epson ... Your Playstation (PDF), PSP, or your Nintendo DS wifi (PDF) Software from Adobe, Hitachi, Oracle and HP Some Nokia phones(PDF)

I thought the problem was the recommended implementation of Dual EC PRNG that was broken - the specific point selection that was mandated to be suitable for government use - the one that RSA used?

Reply on news.ycombinator.com