Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Andi Kleen <ak@suse.de>]

Richard Gooch <rgooch@ras.ucalgary.ca> writes:

> Theodore Tso writes:
> > On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> > > 
> > > The primary reson of invention of /dev/random was the need
> > > for a bit of salt to the initial packet sequence number inside
> > > the networking code in linux. And for this purspose the
> > > whole /dev/*random stuff is INDEED a gratitious overdesign.
> > > For anything else crypto related it just doesn't cut the corner.
> > 
> > A number of other people helped me with the design and development of
> > the /dev/random driver, including one of the primary authors of the
> > random number generation routines in PGP 2.x and 5.0.  Most folks feel
> > that it does a good job.
> 
> Indeed. If Martin has some deep insight as to why the /dev/random
> implementation is insufficient for strong crypto, I'd like to hear
> it.

The only flaw I see in the random device is that its enviromental constraints
are not sufficiently documented.

It is rather unreliable on boxes with no hard disk IO or 
non supported hard disk IO (i.e. until recently a lot of RAID controllers
didn't feed entropy) and no keyboard/mouse -- that is on a lot of appliances
and servers. The box has some random pool still left over from installation,
which gets smaller and smaller over runtime until urandom quickly degenerates
to a not-so-great-and-slow pseudo random generator and /dev/random turns into 
a DoS.

It is not that they are hard to fix; e.g. a $10 sound card
with a noise generating circuit on input and a small daemon to feed
/dev/audio to /dev/random can do it; but few people seem to know about
these problems and still trust the session key generation of their sshd 
(which uses /dev/urandom BTW I guess because of these problems) on their 
headless servers. The both SSL libraries I checked (mozilla and openssl)
do not even seem to use it at all.

-Andi