lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 May 2008 11:14:58 -0400
From:	Bill Fink <>
To:	Alejandro Riveira Fernández 
Cc:	Theodore Tso <tytso@....EDU>, Glen Turner <>,
	Chris Peterson <>,
	Alan Cox <>,
	Lennart Sorensen <>,
	Jeff Garzik <>,
	"Kok, Auke" <>,
	Rick Jones <>,
	"Brandeburg, Jesse" <>,,
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses of

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

> El Sun, 25 May 2008 19:27:12 -0400
> Theodore Tso <tytso@....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.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists