On Thu, Aug 07, 2008 at 02:13:27AM -0700, David Schwartz wrote:
> If so, this doesn't say that /dev/urandom never blocks. It just says that it
> will not block waiting for more entropy. In fact, this paragraph is horribly
> misleading, because it suggests that the worst thing /dev/urandom can do is
> return random values with a theoretical vulnerability. Alas, this is not
> true. The /dev/urandom interface will happily return entirely predictable
> values if the pool was never seeded.
In practice, most Linux distributions (and certainly all of the major
ones), extract content from /dev/urandom and save it across boot
sessions. So the once the system becomes seeded, it stays seeded.
Yes, if you assume that an attacker can remove the hard drive and
access the urandom seed file across reboots, you're in trouble -- but
the attacker can also replace the kernel with one that contains a
keyboard logger, so you'd be even more f*cked.
The question then is how do you make sure the system is correctly
initially seeded. This fundamentally depends on the distribution
installer. If there is sufficient keyboard/mouse activity while the
system is booted, and the distribution saves the result to urandom
seed file, then the system can be seeded from its first boot.
However, if you are worried about systems where you're booting off of
a CD, and/or where the system is getting installed without any human
intervention, then yes, there is need to be concerned. The problem
gets worse if you are booting off of flash where there is entropy
gained by trying to get timings from any kind of spinning storage. At
some level, security systems really need to be designed from a system
perspective, and so there is a quesiton how much of this can or should
be solved inside the kernel or inside the openssl library.
The argument for doing something where you are worried about the
initial seeding problem is probably one where we want to make the
system more robust against clueless application programmers/system
engineers trying to put together security solutions. I can think of
some potential solutions; for example, we can set a flag which is set
once root has written at least 256 bytes to /dev/random (or
/dev/urandom; they share the same input pool), OR once the input pool
has gained at least 64 bytes of entropy credits. And then we could
have an ioctl which blocks until that that flag is set.
- Ted
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
