# NIST Finally Removes NSA-Compromised Crypto Algorithm From Random Number Generator Recommendations

### from the *took-'em-long-enough* dept

Back in December, it was revealed that the NSA had given RSA $10 million to push weakened crypto. Specifically, RSA took $10 million to make Dual Elliptic Curve Deterministic Random Bit Generator, better known as Dual_EC_DRBG, as the default random number generator in its BSAFE offering. The random number generator is a key part of crypto, because true randomness is nearly impossible, so you need to be as random as possible. If it’s not truly random, you’ve basically made incredibly weak crypto that is easy to break. And that’s clearly what happened here. There were other stories, released earlier, about how the NSA spent hundreds of millions of dollars to effectively take over security standards surreptitiously, including at least one standard from the National Institute of Standards and Technology (NIST). People quickly realized they were talking about Dual_EC_DRBG, meaning that the algorithm was suspect from at least September of last year (though there were indications many suspected it much earlier).

In response to all this, NIST quickly issued an announcement recommending against using Dual_EC_DRBG, but it didn’t finally remove it from its random number generator recommendations until this week — following through on an open comment process on changing its recommendations.

Following a public comment period and review, the National Institute of Standards and Technology (NIST) has removed a cryptographic algorithm from its draft guidance on random number generators. Before implementing the change, NIST is requesting final public comments on the revised document,

Recommendation for Random Number Generation Using Deterministic Random Bit Generators(NIST Special Publication 800-90A, Rev. 1).The revised document retains three of the four previously available options for generating pseudorandom bits needed to create secure cryptographic keys for encrypting data. It omits an algorithm known as Dual_EC_DRBG, or Dual Elliptic Curve Deterministic Random Bit Generator. NIST recommends that current users of Dual_EC_DRBG transition to one of the three remaining approved algorithms as quickly as possible.

In September 2013, news reports prompted public concern about the trustworthiness of Dual_EC_DRBG. As a result, NIST immediately recommended against the use of the algorithm and reissued SP 800-90A for public comment.

Some commenters expressed concerns that the algorithm contains a weakness that would allow attackers to figure out the secret cryptographic keys and defeat the protections provided by those keys. Based on its own evaluation, and in response to the lack of public confidence in the algorithm, NIST removed Dual_EC_DRBG from the Rev. 1 document.

In the announcement, NIST also points out that it’s reviewing its cryptographic standards development process, to try to prevent this sort of thing from happening again.

Filed Under: compromised, crypto, dual ec drbg, nist, nsa, random number generator

## Comments on “NIST Finally Removes NSA-Compromised Crypto Algorithm From Random Number Generator Recommendations”

## I don't think Dual_EC_DRBG is unsafe per se

The way I understood this, it becomes unsafe once somebody gets to name the (fixed) constants in use. If those constants are calculated rather than picked randomly, the one providing the constants for use in the standard has an easy hook into the inner state of the random generator.

So it’s not unsafe per se. It’s just that the one proposing the constants may have a secret master key into all communication. And the NSA is not likely bribing RSA and NIST out of goodness of heart.

## Re: I don't think Dual_EC_DRBG is unsafe per se

This is true, however the specific constants that should be used are

partof the Dual_EC_DRBG ‘standard’. While you can use your own constants, it wouldn’t be Dual_EC_DRBG anymore, but a derivative that just happens to share a lot with it.This is why, when cryptographic constants must be chosen, you typically pick a ‘nothing up my sleeve’ number.

## Re: Re: I don't think Dual_EC_DRBG is unsafe per se

I was beaten to it. Bravo

## Re: I don't think Dual_EC_DRBG is unsafe per se

I don’t think you understand the problem here

The problem isn’t the algorithm itself (as far as any crypologist can tell) it’s that the recommendation includes specifications for the random number generator, which DOES produce the hidden numbers needed to break the algorithm.

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

Which is why there is such a fit over this. You can’t be NIST compliant and not use only one part of this. The random number generator and this algorithm go hand in hand for companies who are NIST compliant (See: RSA). So there is literally no telling now many RSA devices are now compromised because of this discovery.

The numbers themselves in the generator have not been found yet. But they will be someday, which means all that information that was encrypted using it will be vulnerable.

## Re: I don't think Dual_EC_DRBG is unsafe per se

It’s more than just “the constants were chosen”. See http://projectbullrun.org/dual-ec/ for more of the shenanigans.

They include a change in the standard to make it less safe. An extension to another standard to make it leak more information. All with specious reasoning.

What’s funny is that they removed it only because of “community feedback”.

What exactly NIST’s purpose then…? Rubber stamping NSA protocols?

## Re:

“…an agency of the U.S. Department of Commerce”

– and thus subject to the FBI and NSA interference.

You are correct. The NIST’s purpose is the same as Microsofts, Googles, IBM’s , and any US Corperation or US Government Department.

Be an agent of NSA. Assist in Industrial Espionage , and blame it all on the hunt for terrorism.

One presumes the Chanceller of Germany is a Terrorist , since they bugged her phone and the phones of all her aids , and refuse to stop.

“In the announcement, NIST also points out that it’s reviewing its cryptographic standards development process, to try to prevent this sort of thing from happening again.”

Step 1 – Maybe stop taking piles of cash and not asking who it came from.

Step 2 – Maybe hire someone who can maybe like check to make sure your not offering the illusion of crypto.

## Re:

Step 3 – Make your business dealings public

Step 4 – Have security throw their managers out of the building, preferably via dropkicks from the second floor

Step 5 – Investigate all changes said managers were a part of

Step 6 – Throw their stuff off the roof, try to aim for their cars

## Re:

I think it’s more likely they’re revising the process to do a better job of hiding the NSA’s fingerprints.

## Re:

They will fail in their “Try to prevent…”

Why ?

Because they are a US Government department subject to the will of the NSA and the president.

I hope you like getting it up the (ahem) , because like Obama, they have no intention of stopping. The best that can be hoped for is that they’re slow and gentle about it.

Either way. Dual_EC_DRBG is a slow, unoptimized, cpu intensive piece of crap. Having a backdoor built in doesn’t help much either.

## Deterministic

Any cryptosystem that has the word deterministic in should be considered suspect.

It is easy to determine the results of the Random Number Generation Using Deterministic Random Bit Generator.

Really, who did not see this coming?

I bet some dude at the NSA is laughing.. “Ha, bunch of morons! I even choose a name that describes our intention and it took them this long to figure it out. What an awesome job I have, I am so evil, muwahaaaaaa!

## Re: Deterministic

It’s the opposite, all cryptosystems should be deterministic.

The playstation hack happened because they didn’t use a deterministic variation of ECDSA. The common (non-deterministic) variation of ECDSA depends on a unique random number; if that number is ever not unique (even if just a few bits are constant), it leaks the private key.

A deterministic random bit generator is related to a stream cipher (and in fact, most common fast DRBGs are directly based on stream ciphers or the similar CTR modes). As long as the initial “seed” is truly random, the output is completely unpredictable to anyone who does not know the seed. You only need true randomness for the seed, and for periodic reseeding (or adding more randomness to the seed).

## Still waiting for the explanation

of where Clapper is not a traitor and a felon.