6 ms·

And here is the mailing list thread that the author refers to: https://lkml.org/lkml/2011/7/29/366 https://lkml.org/lkml/2011/7/29/366

by guns 13y ago

jspaur 13y ago
And even Linus talks about the NSA in that same thread a little lower: https://lkml.org/lkml/2011/7/30/116 https://lkml.org/lkml/2011/7/30/116
- newman314 13y ago
  And the next email where Ted says that the NSA are one of the good guys... Yeah, not so much.
  - tptacek 13y ago
    You just took T'so's quote totally out of context in order to make a fatuous point. In reality, Torvalds and T'so have a better understanding of software security topics than virtually anyone who comments on HN.
  - mpyne 13y ago
    Yeah, how dare the NSA develop SELinux and SHA-1. I suppose I would just be feeding the conspiracy theories if I mentioned that NSA also pushed security work for X.org forward?
  - javert 13y ago
    For anyone wondering, he literally does not say that. He says if you're in the government they're one of the good guys, if you're anyone else you want to mix the results of their RNG with some other source. Which is apparently exactly what this patch does.
andrewcooke 13y ago
even after reading all that it's not clear to me whether the output from rdrand (the hardware instruction from intel that's opaque, if i'm understanding right) is mixed with other sources of entropy or not. at https://lkml.org/lkml/2011/7/30/116 https://lkml.org/lkml/2011/7/30/116 linus says We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. but then goes on to say I'd be even more willing to just take something that just introduces a per-arch interface to get a "unsigned long [ptr]" that is random, and returning the number of bits of expected entropy in that thing. And for x86 CPU's with the RDRAND capability bit, I'd give Intel the benefit of the doubt and just make it do a single "rdrand" and return the full 64 bit [...] which sounds like it would not be mixed. so what was the final outcome? [also, perhaps worth mentioning explicitly - the argument that you shouldn't care too much about this is that if you don't trust intel then you're fucked anyway. which doesn't fill me with warmth and joy, but what can you do?]
semenko 13y ago
There was a lot more follow-up later, see e.g. https://lkml.org/lkml/2012/7/5/422 https://lkml.org/lkml/2012/7/5/422 The important commit here is: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... Excerpted: Change get_random_bytes() to not use the HW RNG, even if it is avaiable. The reason for this is that the hw random number generator is fast (if it is present), but it requires that we trust the hardware manufacturer to have not put in a back door. (For example, an increasing counter encrypted by an AES key known to the NSA.) It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure.
- deleted 13y ago
  [deleted]
  - andrewcooke 13y ago
    my understanding (and i'm not an expert - just trying to help with the discussion) is that getting sufficient entropy is quite hard. i vaguely remember at least one issue, perhaps on startup, where there was insufficient entropy to do something, and so people switched to some other less random source and screwed everything. so if this reports unlimited (or at least, larger than anything else) entropy then there are likely situations where it's the only source available (people don't typically have lava lamps wired up). and then an attack seems possible. [edit: while startup is the case of the bug i remember, you might "consume" entropy faster than it is generated at other times too (i imagine a server running https has a fairly high demand for entropy, for example).]
    - vilda 13y ago
      That's why Linux distros save the entrhopy pool when rebooted. /var/lib/urandom/random-seed in Debian

And here is the mailing list thread that the author refers to: https://lkml.org/lkml/2011/7/29/366 https://lkml.org/lkml/2011/7/29/366

by guns 13y ago

And here is the mailing list thread that the author refers to: https://lkml.org/lkml/2011/7/29/366 https://lkml.org/lkml/2011/7/29/366

jspaur 13y ago

And even Linus talks about the NSA in that same thread a little lower: https://lkml.org/lkml/2011/7/30/116 https://lkml.org/lkml/2011/7/30/116

newman314 13y ago
And the next email where Ted says that the NSA are one of the good guys... Yeah, not so much.
- tptacek 13y ago
  You just took T'so's quote totally out of context in order to make a fatuous point. In reality, Torvalds and T'so have a better understanding of software security topics than virtually anyone who comments on HN.
- mpyne 13y ago
  Yeah, how dare the NSA develop SELinux and SHA-1. I suppose I would just be feeding the conspiracy theories if I mentioned that NSA also pushed security work for X.org forward?
- javert 13y ago
  For anyone wondering, he literally does not say that. He says if you're in the government they're one of the good guys, if you're anyone else you want to mix the results of their RNG with some other source. Which is apparently exactly what this patch does.

andrewcooke 13y ago

even after reading all that it's not clear to me whether the output from rdrand (the hardware instruction from intel that's opaque, if i'm understanding right) is mixed with other sources of entropy or not. at https://lkml.org/lkml/2011/7/30/116 https://lkml.org/lkml/2011/7/30/116 linus says We still do our own hashing on top of whatever entropy we get out of rdrand, and we would still have all our other stuff. but then goes on to say I'd be even more willing to just take something that just introduces a per-arch interface to get a "unsigned long [ptr]" that is random, and returning the number of bits of expected entropy in that thing. And for x86 CPU's with the RDRAND capability bit, I'd give Intel the benefit of the doubt and just make it do a single "rdrand" and return the full 64 bit [...] which sounds like it would not be mixed. so what was the final outcome? [also, perhaps worth mentioning explicitly - the argument that you shouldn't care too much about this is that if you don't trust intel then you're fucked anyway. which doesn't fill me with warmth and joy, but what can you do?]

semenko 13y ago

There was a lot more follow-up later, see e.g. https://lkml.org/lkml/2012/7/5/422 https://lkml.org/lkml/2012/7/5/422 The important commit here is: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... Excerpted: Change get_random_bytes() to not use the HW RNG, even if it is avaiable. The reason for this is that the hw random number generator is fast (if it is present), but it requires that we trust the hardware manufacturer to have not put in a back door. (For example, an increasing counter encrypted by an AES key known to the NSA.) It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure.

deleted 13y ago
[deleted]
- andrewcooke 13y ago
  my understanding (and i'm not an expert - just trying to help with the discussion) is that getting sufficient entropy is quite hard. i vaguely remember at least one issue, perhaps on startup, where there was insufficient entropy to do something, and so people switched to some other less random source and screwed everything. so if this reports unlimited (or at least, larger than anything else) entropy then there are likely situations where it's the only source available (people don't typically have lava lamps wired up). and then an attack seems possible. [edit: while startup is the case of the bug i remember, you might "consume" entropy faster than it is generated at other times too (i imagine a server running https has a fairly high demand for entropy, for example).]
  - vilda 13y ago
    That's why Linux distros save the entrhopy pool when rebooted. /var/lib/urandom/random-seed in Debian