4 ms·

What Linus correctly points out is that when multiple sources of entropy are combined, no single source can act to diminish the sum total of entropy. Even if rd

What Linus correctly points out is that when multiple sources of entropy are combined, no single source can act to diminish the sum total of entropy. Even if rdrand was comprehensively backdoored and entirely predictable by the US government, it's still going to improve the quality of randomness. At worst it's a wash, but it will never reduce it. Here's the direct link to Linus Torvalds' entertaining observation: http://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4/responses/9066 http://www.change.org/en-GB/petitions/linus-torvalds-remove-...

masklinn 13y ago
> You recall correctly indeed No, the situations and concerns are very different.
- sjwright 13y ago
  The situations are indeed different because it's FreeBSD and not Linux. And there's different history behind their /dev/random implementations. But the underling concern is the same: a lack of trust for rdrand -- and the solution should be the same: to only ever use rdrand as an "improver" and never as an actual source of entropy.
  - masklinn 13y ago
    The difference is that Linux already didn't trust RdRand, and didn't use RdRand as the sole input to /dev/random.
    - sjwright 13y ago
      You're right, the OP's post was badly worded, possibly mistaken, as it implies that the change Linus refused to make was analogous to this change.
mnw21cam 13y ago
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.

masklinn 13y ago

> You recall correctly indeed No, the situations and concerns are very different.

sjwright 13y ago
The situations are indeed different because it's FreeBSD and not Linux. And there's different history behind their /dev/random implementations. But the underling concern is the same: a lack of trust for rdrand -- and the solution should be the same: to only ever use rdrand as an "improver" and never as an actual source of entropy.
- masklinn 13y ago
  The difference is that Linux already didn't trust RdRand, and didn't use RdRand as the sole input to /dev/random.
  - sjwright 13y ago
    You're right, the OP's post was badly worded, possibly mistaken, as it implies that the change Linus refused to make was analogous to this change.

mnw21cam 13y ago

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.