4 ms·

Does Dale Emmons reply make any sense? I can't imagine how you could "bias" the output of a RNG just by XORing some data in, unless the RNG is already broken. I

by simias 13y ago

Does Dale Emmons reply make any sense? I can't imagine how you could "bias" the output of a RNG just by XORing some data in, unless the RNG is already broken. I guess you could argue that the NSA could find vulnerabilities in the stock linux RNG and then use this XOR to hide data in a side channel or something. Sounds a bit far fetched, although I guess I can't prove him wrong. But if the stock RNG is faulty we're already quite screwed, rdrand or not. I mean if you're willing to believe this could be compromised, why not imagine that intel inserts backdoors in the silicon of all their chips? Why trust the rest of the logic but not the random number generator specifically? EDIT: also, the picture illustrating the petition is pretty terrible: https://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4 https://www.change.org/en-GB/petitions/linus-torvalds-remove... I can't really blame Linus for responding aggressively on that one...

makomk 13y ago
If the data is being supplied by an attacker that knows what it's being XORed with, which in this case it is, they can completely and undetectably control the output of the RNG that way - they simply have to XOR the output they want with the other data and return that, and then the two XORs will cancel out. (It's undetectable because so long as the output of the hardware RNG looks random, it'll still look just as random after XORing it with anything else.)
- defen 13y ago
  You realize that your attack is predicated on the non-hardware RNG already being broken, right?
  - btilly 13y ago
    Not true. If we're going to put on a tinfoil hat, the hardware RNG only needs to be able to have access to memory to figure out where it is likely to be used.
    - deleted 13y ago
      [deleted]
- simias 13y ago
  Right, but how would they know the output of the other RNG? At this point it's just a tinfoil hat theory, you might as well suspect the drivers of your ethernet card or the people who made the lock on your front door.
  - makomk 13y ago
    They'd know the output of the other RNG because our proposed attacker has the ability to embed malicious hardware and/or microcode in your CPU which can access to the full contents of RAM and all CPU registers. (It's a little harder for them to do so than to just backdoor RdRand, but there doesn't seem much point assuming an attacker can do one but not the other.)
    - SEMW 13y ago
      > our proposed attacker has the ability to embed malicious hardware and/or microcode in your CPU which can access to the full contents of RAM and all CPU registers If the threat model under which rdrand can achieve cancelling XORs is one which requires the threat to have access to RAM and CPU registers, combating it by removing rdrand is like demanding the removal of a front gate that's breakable using teleportation. If the attacker has teleportation, forget the gate, they can teleport straight into your house. As Ted Ts'o points out elsewhere in thread, "if the microcode can figure out where the entropy pool is and figure out what it's being XOR'ed with and adjust accordingly, you're toast anyway. No matter what you can do, if the adversary has control of the cpu microcode at that level, the adversary can just modify the returned entropy value in memory".
      - simias 13y ago
        I would be amused to know how many of those people screaming outrage at rdrand run proprietary video driver blobs or use other closed source operating systems. Priorities, people, priorities.
optimiz3 13y ago
Dale's reply does make sense. While it is true that: <random data> ^ <compromised random data> = <random data> If <compromised random data> has prior knowledge about <random data>, it can emit bits to bias the result. I.e. if I know I'm going to be XORed with a 1, I can return a 1 to yield a 0. This is entirely possible in hardware. Especially with instruction decode look-ahead.

by simias 13y ago

makomk 13y ago

If the data is being supplied by an attacker that knows what it's being XORed with, which in this case it is, they can completely and undetectably control the output of the RNG that way - they simply have to XOR the output they want with the other data and return that, and then the two XORs will cancel out. (It's undetectable because so long as the output of the hardware RNG looks random, it'll still look just as random after XORing it with anything else.)

defen 13y ago
You realize that your attack is predicated on the non-hardware RNG already being broken, right?
- btilly 13y ago
  Not true. If we're going to put on a tinfoil hat, the hardware RNG only needs to be able to have access to memory to figure out where it is likely to be used.
  - deleted 13y ago
    [deleted]
simias 13y ago
Right, but how would they know the output of the other RNG? At this point it's just a tinfoil hat theory, you might as well suspect the drivers of your ethernet card or the people who made the lock on your front door.
- makomk 13y ago
  They'd know the output of the other RNG because our proposed attacker has the ability to embed malicious hardware and/or microcode in your CPU which can access to the full contents of RAM and all CPU registers. (It's a little harder for them to do so than to just backdoor RdRand, but there doesn't seem much point assuming an attacker can do one but not the other.)
  - SEMW 13y ago
    > our proposed attacker has the ability to embed malicious hardware and/or microcode in your CPU which can access to the full contents of RAM and all CPU registers If the threat model under which rdrand can achieve cancelling XORs is one which requires the threat to have access to RAM and CPU registers, combating it by removing rdrand is like demanding the removal of a front gate that's breakable using teleportation. If the attacker has teleportation, forget the gate, they can teleport straight into your house. As Ted Ts'o points out elsewhere in thread, "if the microcode can figure out where the entropy pool is and figure out what it's being XOR'ed with and adjust accordingly, you're toast anyway. No matter what you can do, if the adversary has control of the cpu microcode at that level, the adversary can just modify the returned entropy value in memory".
    - simias 13y ago
      I would be amused to know how many of those people screaming outrage at rdrand run proprietary video driver blobs or use other closed source operating systems. Priorities, people, priorities.

optimiz3 13y ago

Dale's reply does make sense. While it is true that: <random data> ^ <compromised random data> = <random data> If <compromised random data> has prior knowledge about <random data>, it can emit bits to bias the result. I.e. if I know I'm going to be XORed with a 1, I can return a 1 to yield a 0. This is entirely possible in hardware. Especially with instruction decode look-ahead.