[solarexplorer]

The argument is that RDRAND may have access to the previously generated OTP. If that is true, a malicious RDRAND can cancel out any randomness from that OTP. In that case the "incredibly powerful encryption algorithm" XOR can be tricked to generate a stream of zeros, shakespeares complete works, or whatever you like.

[zamalek]

Agreed. However any form of "tricking" would be ultimately pointless because a small adjustment could be made to random.c. Existing CPUs can't be "changed" (barring microcode, but avoiding that is simple - don't install new microcode) so they would no longer work against the system.

In addition the amount of transistors required to actively circumvent random.c is prohibitive: CPUs would need to be significantly larger to pull off attacks like this.

[XorNot]

Who the christ is feeding the output of /dev/random for its use as a cryptographic function without checking that what they read is in fact NOT just a stream of zeroes? Because that's an outcome which can happen from any truly random number generator just by chance - its unlikely, but not unreasonable.

Hence debiasing and the like.

[Peaker]

If they can make it look like a stream of zeros, they can make it look like a random stream which is actually a pseudo-random stream as well.

Also, they might leave some randomness in, but it can be a small enough amount of entropy that it would still render crypto keys vulnerable.

[XorNot]

Doi. This is an obvious danger and I feel stupid for not putting two and two together.