Guys, go read drivers/char/random.c. Then, learn about cryptography. Finally, come back here and admit to the world that you were wrong. Short answer: we actually know what we are doing. You don't. Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of RdRand actually improves the quality of the random numbers you get from /dev/random. Really short answer: you're ignorant. (Linus Torvalds)There is a German saying from Max Frisch which I really like:
Man sollte die Wahrheit dem anderen wie einen Mantel hinhalten, dass er hineinschlüpfen kann – nicht wie ein nasses Tuch um den Kopf schlagen.(rough translation: you should help people to understand the truth and not just throw it around their head like a wet rag) Linus often (always?) uses the wet rag method. Now to the arguments: Actually Tayler Hornby did read random.c and pasted it with some comments on pastebin and explains his arguments in the comments at the end of the file. He says that even though different sources for the random number are used they are XORed together. The RdRand instruction could be smart enough to produce purposely a number which is the inverse of the bits it is going to be XORed with so the result of the XOR operation will be zero. Well maybe RdRand is smart enough to find out that it is called from the Linux Kernel then it must still find the other bits its result will be XORed with to find out which bits it must return. Brad Peabody left a nice comment to this:
The point being made by Taylor is that rdrand could be "smart" enough to understand the state of the rest of the random number generator (which would require reading various state information from a combination of CPU cache, registers or memory) and use that to intentionally spoil the output of the function. This is a no-issue. If that is the case and the CPU is being tampered with in such a way as to perform this kind of sophisticated attack, then why does one xor even matter? As he points out already: "This is the CPU, remember. It can pretty much do anything it wants." Changing the number generation to exclude rdrand isn't going to improve security.I think this is the answer that Linus should have given to be really helpful.
And Theodore Ts'o (the author of random.c) comment to the petition is much smarter (than Linus comment):
I thought of this issue over a year ago. See: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 https://plus.google.com/117091380454742934025/posts/SDcoemc9V3Jand
To Dale's question, if the microcode can figure out where the entropy pool is and figure out what it's being XOR'ed with and adjust accordingly, you're toast anyway. No matter what you can do, if the adversary has control of the cpu microcode at that level, the adversary can just modify the returned entropy value in memory. Realistically, there are real limits to what you can do in the cpu microcode, especially if you are trying to remain covert and be undetectable by people who are testing the CPU, both inside Intel and people who are doing low-level OS work. You need to keep modifications which subvert security software to the bare minimum, or else someone will eventually notice.