Hacker News Reader

Comment by tptacek | Hacker News Reader

It's an awfully weird trojan horse --- or, as Daniel Franke put it on Twitter, a trojan platypus.

First: NIST RNG designs aren't particularly important (unlike the curve standards); there is a broad diversity of CSPRNG designs, applications tend to "borrow" the OS's, and no OS I know of uses a design taken directly from NIST.

Second: Dual EC DRBG is a CSPRNG that uses elliptic curve point multiplications; in other words, it requires bignum math. If you're unfamiliar with CSPRNG design: that's not a normal requirement. Dual EC is very slow. Nobody would willingly use it.

Why would that be the big NSA standard back door? I'm not saying it isn't. Something hinky happened there. I'm just asking: what did they have to gain from trying to backdoor that standard?

View on HN

> It's an awfully weird trojan horse --- or, as Daniel Franke put it on Twitter, a trojan platypus.

Heh, that is a pretty good term for it.

> no OS I know of uses a design taken directly from NIST.

Except for all of the pressure recently on the Linux kernel developers to use Intel's RdRand directly rather than mixing it into their existing entropy pool (see, for example, https://plus.google.com/117091380454742934025/posts/SDcoemc9... and https://lkml.org/lkml/2013/9/5/212), where apparently the reason is "Customers want a SP800-90 source available through the OS interface" (quote from David Johnston, designer of the RdRand hardware, on the Google Plus link).

So, apparently there is a lot of pressure to get the OS to adopt the NIST standards directly.

There are lots of reasons for this kind of pressure. Obviously, if you sell to the government, it'll be easier if you follow the NIST standards. There are likely lots of other compliance related reasons you would want to, such as encryption requirements for HIPAA. I wouldn't be surprised if some of those standards either required or were easier to comply with if you just used NIST approved algorithms, and it's easiest to use those NIST algorithms systemwide if the OS CSPRNG uses them (and directly, without extra unapproved random number generation on top).

> Second: Dual EC DRBG is a CSPRNG that uses elliptic curve point multiplications; in other words, it requires bignum math. If you're unfamiliar with CSPRNG design: that's not a normal requirement. Dual EC is very slow. Nobody would willingly use it.

Yes, this is the odd part. On the other hand, you do have to recall that the NSA is a big government bureaucracy. It may be that their SIGINT enablement department (the one that's responsible for weakening exportable crypto, planting backdoors, and the like) had promised to get some backdoors into widely used standards, but couldn't find a better way to do so surreptitiously and effectively without weakening security against foreign attackers as well.

It may be that Dual EC DRBG was just inserted so they could check off a box and continue to get funding for the standards body division of SIGINT enablement, and not as an actually realistic attack.

> but couldn't find a better way to do so surreptitiously and effectively without weakening security against foreign attackers as well.

Have we seen any evidence that the NSA cares _at all_ about avoiding "weakening security against foreign attackers" in their quest to weak security against themselves as attackers?

Aren't they _neccesarily_ weakening security against foreign attackers when they intentionally weaken crypto, which we now know they do?

It's unclear what the NSA thinks it's doing.

Backdooring the RNG, if they can keep the trapdoor secret(and the NSA would think that, despite the fact that given Snowden, it seems they have some security problems), doest obviously weaken security against foreign attackers who don't have the key unless they can solve the discrete log problem. Plus, it's possible(I think likely) they didn't intend for it to be widely used( it's slow as hell after all and they knew that), but wanted it on systems so they could swap it out for targeted attacks.

Weakening crypto standards(as the NYT reported), on the other hand, seems very counter productive. Though I suppose from the NSA's point of view, it depends which standards. Screwing with IPSEC would seem to hurt US national security and they've been accused of doing that. Screwing with the encryption standards of mobile phone voice communications, on the other hand, would seem to have a far lower consequence.

> Aren't they _neccesarily_ weakening security against foreign attackers when they intentionally weaken crypto, which we now know they do?

No. In fact, most of the schemes that we know about in which they have tried to weaken crypto have involved them having some secret key which can be used to crack it, but without which you don't have a better attack than the standard brute-force attack.

That's the case with Dual EC DRBG. What researches discovered was that the constants in it could have been picked such that with knowledge of a secret constant, you can predict future output given only a relatively small amount of past output. Without knowing those constants beforehand, you wouldn't be able to do better than brute force.

Previous attempts have been similar; the Clipper Chip was supposed to have strong crypto, but store a master key in escrow with the NSA that they could use to crack it. Lotus Notes would encrypt part of the session key with a public key, for which the NSA had a corresponding private key, so if the NSA wanted to eavesdrop they could decrypt that and use it to speed up the brute-forcing process[1].

So, there are numerous cases of the NSA trying to balance the need for crypto that is strong for other attackers, while leaving them a backdoor that only they can use.

1: http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html

> applications tend to "borrow" the OS's, and no OS I know of uses a design taken directly from NIST.

Windows has support for it (although it's up to applications to choose to use it or not).

If it's part of a standard then it might be required by some organisations. For example other government/military agencies and people dealing with them. They could also look to pass laws to require corporations protect their customers private data using the standard. And just have people recommend the standard to everyone, after all was designed by NIST/NSA.

It's also likely to end up in software that wants to support those use cases which could have seen it filter out to other uses. And possibly hardware support.

If the potential for a backdoor hadn't been discovered people wouldn't have objected/noticed.

> Dual EC is very slow. Nobody would willingly use it.

Which leaves the question of why it would end up in the NIST standard if it's not very good.

Of course maybe they where just testing the waters.

Prior to this(or maybe Crypto 2007 where the suspicions were first aired), would you have have batted an eye if you saw Dual_EC_DRBG in a code base with some configuration bit for which NIST RNG you used?

Messing with the standard gets a backdoored RNG onto almost every system. Now NSA just has to convince companies to use it( and it's a NIST standard, so the company has some deniability) or surreptitiously swap it out.

Microsoft's CNG api has a default random number generator. How hard would it be to detect if that default was switched to BCRYPT_RNG_DUAL_EC_ALGORITHM for say, all windows copies sent to Iran or China?

I wouldn't have batted an eye, no. But that's not my point; what makes it weird isn't how poorly the "trojan" was hidden, but in what a pointless place it was hidden.

The "backdoor Chinese Windows" idea is plausible, though.

Saw this pointed out in an LWN comment:

> Apparently, RSA Security BSAFE Share for Java 1.1 has DUAL_EC_DRBG as a default:

> "The default Pseudo Random Number Generator (PRNG) is the Dual EC-DRBG using a P256 curve with prediction resistance off."

> I didn't find an obvious link for the equivalent C/C++ library documentation, but the RSA BSAFE CNG Cryptographic Primitives Library 1.0 FIPS 140-1 Security Policy document from RSA Security at the NIST site says (p.14):

> "The Module provides a default RNG, which is the Dual EC DRBG, using a P256 curve and SHA-256."

https://lwn.net/Articles/566329/

So yes, there are real products out there using Dual EC DRBG. In other news, never trust any crypto from RSA Security. After the SecureID fiasco, and this, it's pretty clear that they are not worth trusting for anything security related.

The best explanation is probably that NSA isn't infallible. Like any government organization, they do things that turn out not to be very effective.

Total tin foil hat territory here, but I see two explanations:

1) they didn't know it was going to be unpopular and dog slow when they started out.

2) they knew it was going to be unpopular and dog slow and didn't invest much time in covering their tracks.

I've actually seen someone choose to use Dual EC DRBG until I yelled "NOOOO DONT": Their software was implementing ECDSA signing, so all the primitives were already there!

It doesn't matter if you have all the primitives. The problem isn't that it's hard to code; the problem is that it's very slow.

Reply on news.ycombinator.com