Hacker News Reader

Comment by sjwright | Hacker News Reader

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-...

View on HN

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.

  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)

  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.

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?

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.

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.

Yeah, in fact someone did a neat PoC of this using virtualization software the other day: 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.)

Fantastic example of what I was saying. Thanks for that.

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.

That's a more fragile attack though, since it requires identifying that memory location.

Really? How?

> You recall correctly indeed

No, the situations and concerns are very different.

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.

The difference is that Linux already didn't trust RdRand, and didn't use RdRand as the sole input to /dev/random.

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.

Reply on news.ycombinator.com