Recent Features
| |||||||||||||
bogus random entropy sourcesbogus random entropy sourcesPosted Oct 6, 2010 11:27 UTC (Wed) by intgr (subscriber, #39733)In reply to: bogus random entropy sources by jzbiciak Parent article: Solid-state storage devices and the block layer
> without getting something more basic and generic like random numbers on there too.
The solution has always been obvious to cryptographers. Use a solid cryptographical pseudorandom RNG; as long as there is _some_ truly random data in its input -- 128 or so bits worth -- the output will always be irreversible. As long as this randomness exists, it doesn't matter that the attacker can predict all other input.
In fact, hardware RNGs should _never_ be used directly, because there may be manufacturing flaws or deliberate sabotage. And unlike deterministic algorithms like AES, non-deterministic hardware RNG sources are almost impossible to verify completely. Also it's really quite easy to replace the hw RNG with a deterministic PRNG that passes all randomness tests, yet whose output is entirely predictable to its designer.
So at most, the hw RNG is just one of several randomness sources on any system. As such cryptographers in general don't consider it worthwhile -- only on diskless embedded systems where there really aren't any entropy sources.
Unfortunately /dev/random is a poor legacy choice in Linux that goes against this concept.
(Log in to post comments)
bogus random entropy sources Posted Oct 7, 2010 12:24 UTC (Thu) by nix (subscriber, #2304) [Link]
"Diskless embedded systems" of course includes "all virtual machines". So there are a lot of them.
bogus random entropy sources Posted Oct 7, 2010 12:48 UTC (Thu) by intgr (subscriber, #39733) [Link]
For virtual machines you already have a paravirtual RNG device called 'virtio-rng' (CONFIG_HW_RANDOM_VIRTIO).
But in general, virtual machine disk I/O still reaches a physical disk sooner or later, so entropy can be successfully gathered from interrupt timings. In some virtualization scenarios, you wouldn't want the VM to access host-CPU-specific features anyway.
|
|||||||||||||