5 ms·
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.
by 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 agomy 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 agoThat's why Linux distros save the entrhopy pool when rebooted. /var/lib/urandom/random-seed in Debian
- deleted 13y ago[deleted]
- andrewcooke 13y agoi'm sorry, this is just incoherent to me. i have no idea what you're trying to say, or how it fits with my comment. i was trying to explain why an untrusted hardware rng cannot be improved in some cases (because of limited entropy from elsewhere). and i don't see how what you are saying addresses that.
- vilda 13y agoFew points: (1) Chaining rnd generators is fine as long as they are not correlated somehow. If there is any correlaton, the output may be weaker. (Consider chainig two exactly same generator as a corner case.) (2) In this case we don't chain generators; you would loose the speed of the integrated one otherwise.
- deleted 13y ago[deleted]