We allow the wild web to have access to our closed source GPU driver blobs but we elaborate tinfoil hat theories about rdrand. This is insane.
Regarding "(I'm not sure I agree with Linus that mixing in a known-tainted RDRAND stream would nevertheless invariably improve randomness, but on the surface, it shouldn't reduce it.)": I think it's fair to say it would, in practice.
Even if the NSA knows how to predict the output of rdrand (because it's really some stream cipher with a known key or something), most people don't. Therefore, it wouldn't improve the randomness of the final stream from the NSA point of view, but it would from the point of view of any other attacker not in the secret. So I think it's fair to say it can't do harm and it can actually do some good.
The consensus seems to be that if the NSA can backdoor rdrand so deeply that it can keep track of the CPU state and the contents of the RAM then you might as well throw away the whole CPU, why would you choose to trust all instructions but rdrand? They could have compromised the interrupt vector, the syscall vector or anything else.
This feels like "rumor based cryptography" or more precisely "FUD based cryptography". We're just running in circles.
This is true. I think it is unlikely that rdrand is this deeply backdoored. However, I do think for something this critical the comments should match the code better and working on fixing the problems identified in the article is probably prudent.
It is worth noting that police used to be able to exploit firewire DMA to bypass disk encryption and copy encryption keys out of memory from any system with a firewire port. This has been fixed and a CPU-level exploit for crypto seems unlikely to me because making something that not only worked consistently but didn't slow down general purpose programming when it worked, would be an engineering marvel.
This being said, having clear, unimpeachable code in these areas is a good start because it helps ensure that other problems are not lurking under the surface.
I agree that the comment of get_random_bytes should be fixed, it's misleading. However I don't think modifying code that has no known bug or weakness because of a rumor and some handwaving is good policy. It's more likely than not to introduce a regression and create real trouble.
If it's ain't broke...
Or in this case:
If you can't prove it's broke...
EDIT: I would also remind everybody that if they really don't trust rdrand for any reason they can just add the "nordrand" boot kernel param and disable this code. It's a non-issue.
> why would you choose to trust all instructions but rdrand
Presumably, there are limits to the amount of silicon that Intel/NSA can devote to backdooring everyone. Since other instructions are supposed to behave deterministically, it could be expensive to backdoor them in a way that would not easily be discovered.
On the other hand, RDRAND could be a straightforward Dual_EC_DRBG implementation, which would be a very cheap and effective backdoor that would also have the nice benefit of keeping people's communications secure against everyone except the NSA.
Of course, there's also the possibility that there's no backdoor, but that the implementation is still buggy.
There's no reason why our trust in the hardware has to be all or nothing.
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.
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.
Regarding "(I'm not sure I agree with Linus that mixing in a known-tainted RDRAND stream would nevertheless invariably improve randomness, but on the surface, it shouldn't reduce it.)": I think it's fair to say it would, in practice.
Even if the NSA knows how to predict the output of rdrand (because it's really some stream cipher with a known key or something), most people don't. Therefore, it wouldn't improve the randomness of the final stream from the NSA point of view, but it would from the point of view of any other attacker not in the secret. So I think it's fair to say it can't do harm and it can actually do some good.
See also the previous discussion:
https://news.ycombinator.com/item?id=6359892
The consensus seems to be that if the NSA can backdoor rdrand so deeply that it can keep track of the CPU state and the contents of the RAM then you might as well throw away the whole CPU, why would you choose to trust all instructions but rdrand? They could have compromised the interrupt vector, the syscall vector or anything else.
This feels like "rumor based cryptography" or more precisely "FUD based cryptography". We're just running in circles.