I never followed this at all prior to reading this article so forgive me if this was covered outside the scope of this write-up, but...
If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statistically random... So why hasn't someone (who thinks RDRAND is a trap) done that instead of just claiming it could maybe be doing something fishy?
Ah but that is not quite as easy as you might think. Maybe RDRAND is actually a keyed PRNG, so it is computationally hard to distinguish from "true" randomness. Maybe there are only 1000000000 possible keys, so while you could theoretically detect the back door, it is impractical/unlikely for anyone with less than NSA resources to do so. Conveniently, the NSA has the resources to exploit such a bias.
To further throw you off, it could be the case that the back door is only exploitable after, say, 1kB of output, and it is "truly random" prior to that. That would be plenty useful for the NSA's purposes. It might even be that the back door is only exploitable for some part of the output, maybe the part where you are most likely to find a suitable prime number during some key generation process. Intel periodically releases new products, so the NSA would have plenty of chances to update the backdoor as software changes.
The gist of the argument as I understand it is that some people think Intel's chip (at the chip level) is taking a look at data that the RDRAND result will be used as an XOR against and using that to mess with the result RDRAND returns in some way to weaken the overall random number.
If this were true and you set up a repeatable test situation in which you force the other parts of the RNG to generate the same numbers prior to RDRAND and then did the RDRAND and captured the results then I don't see how one could argue RDRAND is compromised in this way if the results coming out of it over time even appear to be statistically random.
...unless people think the chip is also detecting situations where you are actively trying to fool it by setting up repeated simulations of the same initial value to be XORed, which strains credibility way beyond what I'm willing to believe.
Actually that is quite simple. For simplicity let us assume RDRAND will only attack the Linux RNG. Now RDRAND first generates its own weak random stream w_k. When it predicts that Linux will generate l_k it outputs l_k xor w_k thus the final output of the Linux RNG will be w_k. As w_k looks random for everyone who does not have the private key you cannot check that there is anything wrong with w_k or w_k xor l_k.
"For simplicity let us assume RDRAND will only attack the Linux RNG."
Assuming the chip is detecting that the Linux RNG is in play is already way out of the realm of simplicity and frankly way beyond what a company like Intel is likely to be able to keep secret given the number of engineers that would have to be aware of this complex functionality.
This whole conspiracy theory hinges on some wild claims that I haven't seen substantiated in the least.
As far as I have followed the discussion there are no hard facts or claims at all, just the general suspicion against a completely closed system of an US company.
I, too, don't believe that Intel adaptively generates its RNG to spoil the Linux RNG. But be reminded that what would have been wild conspiracy theories just half a year ago is now common believe (NSA deliberately introducing vulnerabilities in software and even in cryptographic standards, routinely by-passing TLS).
Given all we know (and don't know) I think it would be prudent to mix Intel's RNG with the other randomness sources using a cryptographically strong primitive and not just XOR. Personally I'm enthusiastic about Keccak as a reseedable RNG, but these modes will probably be standardized no earlier than fall 2014.
> Assuming the chip is detecting that the Linux RNG is in play is already way out of the realm of simplicity
I meant simplicity of my argument. As an answer to this paragraph I argued that it is indeed possible to generate malicious output that appears completely random:
> If this were true and you set up a repeatable test situation in which you force the other parts of the RNG to generate the same numbers prior to RDRAND and then did the RDRAND and captured the results then I don't see how one could argue RDRAND is compromised in this way if the results coming out of it over time even appear to be statistically random.
If the CPU did give you a RDRAND value that was pre-baked to weaken the number it thinks you're going to XOR it against it, it would be easy to detect this by feeding RDRAND the same input state repeatedly and seeing if there is a pattern to what is spit out or if it is indeed statistically random... So why hasn't someone (who thinks RDRAND is a trap) done that instead of just claiming it could maybe be doing something fishy?