I am so glad I resisted pressure from engineers working at Intel to let /dev/random in Linux rely blindly on the output of the RDRAND instructure. Relying solely on an implementation sealed inside a chip and which is impossible to audit is a BAD idea. Quoting from the article...
"By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors..."
Thank you for that, and I hope that the people who keep arguing "if you can't trust your hardware, you can't trust anything, so we may as well just blindly trust the hardware" keep this in mind.
A bug deliberately introduced in an AES instruction, or in general purpose instructions that detects crypto operations and leaks information somehow, is much, much harder to implement and hide than a pseudo-random number generator that passes all tests that you apply to it, but produces predictable output for someone who knows some secret key.
Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.
Matt Mackall, the former maintainer of /dev/random, actually stepped down over this issue, because Linus overrode Matt and applied Intel's patch that used their hardware random number generator directly:
> It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections.
> From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output.
Ted Ts'o later reverted this, separating out Intel's hardware random number generation into a separate function that could be used to seed the entropy pool but wouldn't be trusted directly as the main kernel source of random numbers:
If Matt protested, he did so quietly/privately. I wasn't aware of the fact that he had stepped down until the authors of the paper described in http://factorable.net showed up and pointed out we had a really bad problem for embedded devices on the internet. I had always assumed he had gotten too busy and distracted on other interests, since I do follow LKML, and I didn't see any kind of public debate/controversy about the change to the random driver described above.
If I had to guess what happened, some intel people pushed this as a feature, probably pushing it via one of the x86 git trees, and Linus either (a) didn't notice, or (b) didn't understand the implications, and then Matt quit in a huff --- by just stopping to do work, and not even updating the entry in the MAINTAINERS file. (That didn't happen until I took over the random driver again.)
It doesn't really look like he had NAKed it on paranoia grounds, but more on design grounds; others brought up the paranoia arguments. You were even involved in that thread, so you should have seen his stepping down, although he didn't submit a patch to MAINTAINERS.
You're right, if he did so, it must have been in private; I searched for a while to find a message on a public mailing list about it, and could not, so resorted to linking to that later message.
Regardless, I'm glad that paranoia did eventually prevail, despite Linus's original strong objections.
Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212
"It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure."
---
"The NSA's codeword for its decryption program, Bullrun, is taken from a major battle of the American civil war. Its British counterpart, Edgehill"
"N.S.A. spends more than $250 million a year on its Sigint Enabling Project, which “actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make them “exploitable.”"
"By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors..."