Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Bill Fink <billfink@mindspring.com>]

On Mon, 26 May 2008, Alejandro Riveira Fernández wrote:

> El Sun, 25 May 2008 19:27:12 -0400
> Theodore Tso <tytso@MIT.EDU> escribió:
> 
> > On Mon, May 26, 2008 at 12:39:49AM +0930, Glen Turner wrote:
> > > 
> > > For example, /dev/random has run out. So the output of /dev/urandom
> > > is now determined by previous values of /dev/random.  I then send in
> > > a stack of network packets at regular intervals. So the output of
> > > /dev/urandom is now greatly determined by those packets.  My search
> > > space for the resulting key is small since /dev/urandom appears to
> > > be random, but in fact is periodic.
> > 
> > That's not how it works.  Basically, as long as there is *some*
> > entropy in the system, even from the /var/lib/random-seed, or from
> > keyboard interrupts, or from mouse interrupts, which is unknown to the
> > attacker, in the worse case /dev/urandom will be no worse than a
> > cryptographic random number generator.
> > 
>  [ ... ] 
>  
>  Just a shot in the dark... would hw sensors (raw data) chips be a good source
>  of entropy for /dev/random ?? 

For systems with high resolution timers, even if an attacker has total
knowledge/control of the network, it doesn't seem realistically possible
for them to determine the low order bits of the nanosecond timer of
disk and network I/O system calls, if those were used as a source of
entropy.  I think this is a case of the (unrealistic) best being an
enemy of the common (and realistic) good.

Another idea that occured to me:  How about using the low order bits
of the instruction memory address being executed that was interrupted
by the HZ timer interrupt.  This also doesn't seem to be something
that an external attacker could realistically determine.  And a
combination of these approaches would be that much stronger, combined
of course with any other available entropy sources.

						-Bill