41–50 of 100 posts
I still don't get it.
https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND. I still don't get it.
i distrust
Earlier quoted context omitted.
There was a lot more follow-up later, see e.g. https://lkml.org/lkml/2012/7/5/422 The important commit here is: 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 i…
[deleted]
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).]
> Not to mention, Intel have been in bed with the NSA for the longest time.
> Secret areas on the chip, pop instructions, microcode and all that ...
What does "pop instructions" refer to here?
Earlier quoted context omitted.
There was a lot more follow-up later, see e.g. https://lkml.org/lkml/2012/7/5/422 The important commit here is: 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 i…
[deleted]
(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.
https://lkml.org/lkml/2011/7/31/139 Since there was a minor amount of confusion I want to clarify: RDRAND architecturally has weaker security guarantees than the documented interface for /dev/random, so we can't just replace all users of extract_entropy() with RDRAND. I still don't get it.
For what it's worth, the RDSEED instruction has been announced by Intel a while back (but not yet on current processors), which means to be an NRBG as well.
Earlier quoted context omitted.
[deleted]
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 l…
So this is logic that more or less rules out all hardware encryption, including HSMs, right?
You can trust Skype that calls are encrypted and cannot be eavesdropped, you can trust Verizon that your cellphone metadata are not passed to government automatically, and you can trust Intel that their rnd is not backdoored.
Or you don't.
For those that aren't aware, the security of a rand number generator is very important: http://en.wikipedia.org/wiki/Random_number_generator_attack