3 ms·
fake_random = 5 result = secret ^ real_random result = result ^ fake_random You know the value of fake_random, but the randomness isn't reduced at all (sor
by riquito 13y ago
fake_random = 5
result = secret ^ real_random
result = result ^ fake_random
You know the value of fake_random, but the randomness isn't reduced at all (sorry, I can't produce a real mathematical explanation)
- mnw21cam 13y agocurrent_random = <something unpredictable> fake_random = RDRAND() new_random = current_random XOR fake_random Surprise! new_random is predictable, because the malicious CPU peeked ahead at the XOR operation and adjusted the RDRAND operation accordingly.
- hershel 13y agoCan't you wrap the RDRAND call with some long complicated code , so that tracking what fake_random will be hard to in hardware , thus preventing this attack?
- mnw21cam 13y agoYes, but then it's an arms race between the hardware manufacturer and the random number software writer. The fact is that the Linux/BSD random number generators were actually rather good before all this RDRAND stuff.
- deleted 13y ago[deleted]
- kerkeslager 13y agoTry this again, but instead of: fake_random = 5 Try: fake_random = secret ^ real_random ^ 5 No matter what secret or real_random are, result is now 5. You can't hide secret or real_random from the processor. In a larger sense, there's no way to stop the processor from simply setting result to whatever it wants before returning it to the place where it's used. My point is, there's no real way to trust hardware that can't be verified.