Linus on /dev/random: "We actually know what we are doing. You don't."

Good article if only for "bucket of digital slurry."

Yep.

The main concern about random number generation is that if you use the output of RdRand exclusively, it's fairly easy to backdoor in such a way that it looks completely random to all outside observers, but the NSA has a key that could allow them to predict the output based on past output. However, mixing it with the state of an already good random number generator (which the kernel needs to have anyhow for platforms without an RdRand instruction) pretty much negates that attack.

No one (reasonable) is actually particularly concerned that Intel themselves has backdoored RdRand. But they do want to ensure that they are protected in the case that at some point in the future, some other architecture adds a random number generation instruction and that is backdoored. And since you need to continue to do software random number generation anyhow, the best way to use RdRand is to use both, mix them, and get the best of both worlds (fast entropy available in environments with limited entropy sources, and an auditable software random number generator).

All of the other attacks that people are suggesting require a whole hell of a lot more silicon, require changing the behavior of unrelated instructions, and so on. They're just too complex and too fragile to be feasible.

Instead, why don't we spend our time naming and shaming the companies that actually do use backdoored random number generation, like RSA security:

> 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."

> Additionally, the RSA BSAFE Crypto-C Micro-Edition 3.0.0.2 FIPS 140-1 Security Policy says (p.17):

> "For R_FIPS140_MODE_FIPS140_ECC and R_FIPS140_MODE_FIPS140_SSL_ECC, Crypto-C ME implements a Dual ECDRBG (Cert. #137) internally"

> I'd be more than a bit wary of any product using RSA Security libraries.

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

For a while, people were confused about why the NSA would have gotten the Dual EC DRBG random number generator introduced into a standard, as it's so much slower than most of the other available random number generators, and it was only a year after the standard was released that the potential backdoor was pointed out. Well, apparently RSA has decided that it's the best RNG available, perhaps with some influence from the NSA.

Remember, this is a hardware implementation you're talking about. Nothing is ever "trivial". It would take a significant amount of extra silicon to add this kind of detection logic.

The reason for the basic paranoia about not trusting RdRand directly is that it's pretty easy and cheap to make it generate a random number stream that looks random, but is predictable (the RdRand function already is documented to use AES; all you would need to do is make it do AES of an incrementing integer sequence, rather than actual random noise, which is a pretty small change). And heck, if RdRand isn't backdoored (no one has presented evidence that is is; it's just a standard level of paranoia because subverting the random number generator is a favorite technique of the NSA), it might be in a future version, or AMD or ARMs implementation of a similar instruction in the future may be.

Detecting a code sequence and subverting it would be far more difficult. For one, there's the extra silicon. There's the extra chance of that change introducing other noticeable behaviors. There's the extra chance of discovery. It's just not worth the costs. And furthermore, if you really are worried about that, then there's no reason to limit your paranoia to the RdRand function; you may as well say you can't trust the chip to run any crypto code at all.

This 500MB/s a merged stream when using all cores, I got like 140MB/s on one (from my answer in the SO thread you linked).

And I'm not ranting, I'm just crying over a lost opportunity. Nowadays you must spend time to think which PRNG to use and how to implement it to satisfy some quality/speed trade-off; an RNG (infinite cycle by design) directly connected to CPU (no transfer bottlenecks) that passes Die Hard (read random enough for science) would be a golden bullet.

Yes, PRNG makes RDRAND faster than its entropy source in its current design; but it is not hitting any wall. Intel engineers could made it way faster if they had focused on maximal throughput possible not just big enough for crypto.

Doi. This is an obvious danger and I feel stupid for not putting two and two together.