7 ms·

If I recall correctly, Linus refused to make this change in Linux, denouncing it as paranoia. My fear is that the extra complexity adds additional opportunity

by gnu8 13y ago

If I recall correctly, Linus refused to make this change in Linux, denouncing it as paranoia. My fear is that the extra complexity adds additional opportunity for a back door to be inserted. However, software can be audited, the hardware cannot be.

sjwright 13y ago
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.
salient 13y ago
> However, software can be audited, the hardware cannot be Exactly. So work on solid security/privacy principles, rather than take the easy way out and hope for the best.
masklinn 13y ago
No, Linus has refused to make a different change in Linux (the complete removal of RDRAND) because linux does not directly use RDRAND output, and it already uses RDRAND as an other source of entropy[-1], which is what FreeBSD is moving towards. According to Theodore Ts'o, there was pressure from Intel engineers to rely solely on RDRAND but they were rejected[0], it looks like the FreeBSD devs did do it and have /dev/random using RDRAND/Padlock directly[1] [-1] although — and I don't know why — the linux rng XORs pool output with RDRAND output instead of feeding RDRAND into the entropy pool itself[3] [0] https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+TheodoreTso/posts/SDcoemc9V3J https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+Theo... [1] That's the only way I can interpret "for 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random"[2] anyway [2] http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security http://www.freebsd.org/news/status/report-2013-09-devsummit.... [3] I'll try to stop now but[4] provides a rationale for it: a history of unnoticed bugs in the random pool making the risk of a trivial xor lower as far as kernel devs are concerned: if you xor a known A and an unknown B, you can't know anything about the output (it won't be any more known than B is), whereas if you know of bugs in the random pool you might be able to take advantage of them and skew the output. Make of that what you will. [4] http://thread.gmane.org/gmane.linux.kernel/1323386/focus=1332780 http://thread.gmane.org/gmane.linux.kernel/1323386/focus=133...
- acqq 13y ago
  The last time I've followed, RDRAND was not "just another source" in Linux, as it was xored after another sources were "fully" mixed.
  - masklinn 13y ago
    Yes, I had modified my comment to make note of that. Although I tuned the language a bit more (removed the "just" of "just an other source")
- bluecalm 13y ago
  Any info on why Intel engineers applied the pressure ?
phaemon 13y ago
I think you're mistaken. It looks more like FreeBSD is moving to using these devices the same way Linux already does.
a1a 13y ago
Your comment implies that Linus trusts Intel. This is not true, since the change is unnecessary even if they were infiltrated: "Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random." 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-...
- lvh 13y ago
  The conclusion is arguably correct, but the premise not so much. RDRAND isn't used as an input to the random.c pool: http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-linux/ http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-lin...
andrewaylett 13y ago
No, as I understand that's a different change. The current state of FreeBSD, if I understand correctly, is that it has the option of returning the hardware-generated random sequence directly. They're changing it so it feeds entropy into the pool. Linux does neither, instead it xors the output of the entropy pool with the output from the hardware random number generator. This is strictly no less secure than the entropy pool on its own. Note that the implementation of the systems' entropy pools is also quite different -- my understanding is that FreeBSD uses Yarrow, a pRNG, to feed /dev/random, while Linux mixes bits of 'real' random data together, without the extra pRNG stage. Which of these schemes is better is irrelevant to this particular discussion. No links, I'm afraid, as EE apparently thinks Stack Exchange isn't suitable for under 18s and I can't turn content lock off at the moment.
- masklinn 13y ago
  > This is strictly no less secure than the entropy pool on its own. I'm not quite certain, it should be possible (though possibly overly complex) to use RDRAND (or calls to the crypto routines) as a trigger for a XOR backdoor working in concert with a RDRAND backdoor, and thus control the final output.
  - mnw21cam 13y ago
    It wouldn't actually be that hard for a CPU to notice which register the result of RDRAND was being XORed with and just set that register to something generated instead. Because, you know, that doesn't actually break any contracts. The effect is still that of XORing with a number we didn't know beforehand.
    - sjwright 13y ago
      That assumes we can't read the result of rdrand after the XOR is performed. I don't know the specifics of how the chip RNG is implemented in hardware, but surely its values have to hit some sort of readable memory before the kernel's code performs the XOR?

by gnu8 13y ago

sjwright 13y ago

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.

salient 13y ago

> However, software can be audited, the hardware cannot be Exactly. So work on solid security/privacy principles, rather than take the easy way out and hope for the best.

masklinn 13y ago

No, Linus has refused to make a different change in Linux (the complete removal of RDRAND) because linux does not directly use RDRAND output, and it already uses RDRAND as an other source of entropy[-1], which is what FreeBSD is moving towards. According to Theodore Ts'o, there was pressure from Intel engineers to rely solely on RDRAND but they were rejected[0], it looks like the FreeBSD devs did do it and have /dev/random using RDRAND/Padlock directly[1] [-1] although — and I don't know why — the linux rng XORs pool output with RDRAND output instead of feeding RDRAND into the entropy pool itself[3] [0] https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+TheodoreTso/posts/SDcoemc9V3J https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J#+Theo... [1] That's the only way I can interpret "for 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random"[2] anyway [2] http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security http://www.freebsd.org/news/status/report-2013-09-devsummit.... [3] I'll try to stop now but[4] provides a rationale for it: a history of unnoticed bugs in the random pool making the risk of a trivial xor lower as far as kernel devs are concerned: if you xor a known A and an unknown B, you can't know anything about the output (it won't be any more known than B is), whereas if you know of bugs in the random pool you might be able to take advantage of them and skew the output. Make of that what you will. [4] http://thread.gmane.org/gmane.linux.kernel/1323386/focus=1332780 http://thread.gmane.org/gmane.linux.kernel/1323386/focus=133...

acqq 13y ago
The last time I've followed, RDRAND was not "just another source" in Linux, as it was xored after another sources were "fully" mixed.
- masklinn 13y ago
  Yes, I had modified my comment to make note of that. Although I tuned the language a bit more (removed the "just" of "just an other source")
bluecalm 13y ago
Any info on why Intel engineers applied the pressure ?

phaemon 13y ago

I think you're mistaken. It looks more like FreeBSD is moving to using these devices the same way Linux already does.

a1a 13y ago

Your comment implies that Linus trusts Intel. This is not true, since the change is unnecessary even if they were infiltrated: "Long answer: we use rdrand as _one_ of many inputs into the random pool, and we use it as a way to _improve_ that random pool. So even if rdrand were to be back-doored by the NSA, our use of rdrand actually improves the quality of the random numbers you get from /dev/random." 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-...

lvh 13y ago
The conclusion is arguably correct, but the premise not so much. RDRAND isn't used as an input to the random.c pool: http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-linux/ http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-lin...

andrewaylett 13y ago

No, as I understand that's a different change. The current state of FreeBSD, if I understand correctly, is that it has the option of returning the hardware-generated random sequence directly. They're changing it so it feeds entropy into the pool. Linux does neither, instead it xors the output of the entropy pool with the output from the hardware random number generator. This is strictly no less secure than the entropy pool on its own. Note that the implementation of the systems' entropy pools is also quite different -- my understanding is that FreeBSD uses Yarrow, a pRNG, to feed /dev/random, while Linux mixes bits of 'real' random data together, without the extra pRNG stage. Which of these schemes is better is irrelevant to this particular discussion. No links, I'm afraid, as EE apparently thinks Stack Exchange isn't suitable for under 18s and I can't turn content lock off at the moment.

masklinn 13y ago
> This is strictly no less secure than the entropy pool on its own. I'm not quite certain, it should be possible (though possibly overly complex) to use RDRAND (or calls to the crypto routines) as a trigger for a XOR backdoor working in concert with a RDRAND backdoor, and thus control the final output.
- mnw21cam 13y ago
  It wouldn't actually be that hard for a CPU to notice which register the result of RDRAND was being XORed with and just set that register to something generated instead. Because, you know, that doesn't actually break any contracts. The effect is still that of XORing with a number we didn't know beforehand.
  - sjwright 13y ago
    That assumes we can't read the result of rdrand after the XOR is performed. I don't know the specifics of how the chip RNG is implemented in hardware, but surely its values have to hit some sort of readable memory before the kernel's code performs the XOR?