8 ms·
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
by solarexplorer 13y ago
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.
- XorNot 13y agoWho 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 13y agoIf 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 13y agoDoi. This is an obvious danger and I feel stupid for not putting two and two together.
- zamalek 13y agoAgreed. 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.