3 ms·

It's not true that it will never reduce it. It wouldn't be too hard for a CPU to notice when the result of RDRAND is XORed with something, and do evils to delib

It's not true that it will never reduce it. It wouldn't be too hard for a CPU to notice when the result of RDRAND is XORed with something, and do evils to deliberately control the eventual result.

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 ago
  current_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 ago
    Can'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 ago
      Yes, 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 ago
  Try 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.
makomk 13y ago
Yeah, in fact someone did a neat PoC of this using virtualization software the other day: https://twitter.com/DefuseSec/status/408975222163795969/photo/1 https://twitter.com/DefuseSec/status/408975222163795969/phot... That's with an unmodified Linux kernel and unmodified instruction set aside from RDRAND. (In practice you'd make the result something less obvious than a constant value, but this presumably makes for a clearer demo.)
- mnw21cam 13y ago
  Fantastic example of what I was saying. Thanks for that.
  - rolux 13y ago
    Yes, but as stated further up, that CPU could anyway just write arbitrary data to the memory that holds your entropy pool, if you use RDRAND or not.
    - caf 13y ago
      That's a more fragile attack though, since it requires identifying that memory location.
TsiCClawOfLight 13y ago
Really? How?

It's not true that it will never reduce it. It wouldn't be too hard for a CPU to notice when the result of RDRAND is XORed with something, and do evils to deliberately control the eventual result.

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 ago
current_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 ago
  Can'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 ago
    Yes, 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 ago
Try 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.

makomk 13y ago

Yeah, in fact someone did a neat PoC of this using virtualization software the other day: https://twitter.com/DefuseSec/status/408975222163795969/photo/1 https://twitter.com/DefuseSec/status/408975222163795969/phot... That's with an unmodified Linux kernel and unmodified instruction set aside from RDRAND. (In practice you'd make the result something less obvious than a constant value, but this presumably makes for a clearer demo.)

mnw21cam 13y ago
Fantastic example of what I was saying. Thanks for that.
- rolux 13y ago
  Yes, but as stated further up, that CPU could anyway just write arbitrary data to the memory that holds your entropy pool, if you use RDRAND or not.
  - caf 13y ago
    That's a more fragile attack though, since it requires identifying that memory location.

TsiCClawOfLight 13y ago

Really? How?