Re: /dev/urandom uses uninit bytes, leaks user data

[Theodore Tso <tytso@mit.edu>]

On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
> On a server, keyboard and mouse are rarely used.  As you've described it, 
> that leaves only the disk, and during the boot process, disk accesses and 
> timing are somewhat predictable.  Whether this is sufficient to break the 
> RNG is (clearly) a matter of debate.

In normal operaiton, entropy is accumlated on the system, extracted
via /dev/urandom at shutdown, and then loaded back into the system
when it boots up.  So this will help in everything but the freshly
installed system case (and in that case things will get better as the
system has a chance to operate).

If you have a system with insufficent entropy inputs, you're in
trouble, of course.  There are "catastrophic reseeds" that attempt to
mitigrate some of worse attacks, but at the end of the day,
/dev/random isn't magic.

In any case, the problem if you have insufficent entropy is not
esoteric attacks that presume an attacker can break into the system
and read out kernel memory.  The problem will be /dev/random's entropy
output.  And there are techniques that cryptographic applications can
do to help.  For example, if it is about to encrypt data, it can SHA-1
hash data that it is about to be sent out encrypted, and feed the
SHA-1 hash into /dev/random.  This won't increase entropy credit
counter, but if the attacker doesn't have access to the unecrypted
plaintext, mixing in the SHA-1 hash into /dev/random can only help. 

If you have a server, the best thing you can do is use a hardware
random number generator, if it exists.  Fortunately a number of
hardware platforms, such as IBM blades and Thinkpads, come with TPM
modules that include hardware RNG's.  That's ultimately the best way
to solve these issues.

						- Ted