Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
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.
even after reading all that it's not clear to me whether the output from rdrand (the hardware instruction from intel that's opaque, if i'm understanding right) is mixed with other sources of entropy or not.
at https://lkml.org/lkml/2011/7/30/116 linus says We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. but then goes on to say I'd be even more willing to just take something that just introduces a per-arch interface to get a "unsigned long [ptr]" that is random, and returning the number of bits of expected entropy in that thing. And for x86 CPU's with the RDRAND capability bit, I'd give Intel the benefit of the doubt and just make it do a single "rdrand" and return the full 64 bit [...] which sounds like it would not be mixed.
so what was the final outcome?
[also, perhaps worth mentioning explicitly - the argument that you shouldn't care too much about this is that if you don't trust intel then you're fucked anyway. which doesn't fill me with warmth and joy, but what can you do?]
You just took T'so's quote totally out of context in order to make a fatuous point. In reality, Torvalds and T'so have a better understanding of software security topics than virtually anyone who comments on HN.
For anyone wondering, he literally does not say that.
He says if you're in the government they're one of the good guys, if you're anyone else you want to mix the results of their RNG with some other source.
The important commit here is:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
Excerpted:
Change get_random_bytes() to not use the HW RNG, even if it is avaiable.
The reason for this is that the hw random number generator is fast (if it is present), but it requires that we trust the hardware manufacturer to have not put in a back door. (For example, an increasing counter encrypted by an AES key known to the NSA.)
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.