Security and harddisk crubbing in Linux

[David Gibson]

On Fri, Oct 26, 2001 at 04:56:58PM +1000, Steven Hanley wrote:
> On Fri, Oct 26, 2001 at 04:40:50PM +1000, Sam Couter wrote:
> > Drake Diedrich <dld at coyote.com.au> wrote:
> > >    /dev/urandom would take about a day to generate the necessary ~60G of
> > > pseudorandom data per pass, but you could always write very short programs
> > > (about three lines of C) to generate acceptable patterns instead and cut
> > > that to the hard drive writing speed (about an hour/pass).
> > 
> > Wiggle yer mouse for a while. That should generate a fair bit of
> > entropy.
> 
> entropy generation has nothing to do with the urandom device.
> 
> the /dev/random device uses the entropy pool for giving the most random sort
> of data available. the /dev/urandom device is seeded on system startup and
> then the random data coming out of it is generated algortihmically, however it
> sis a somewhat more indepth way of generating data than necessary for this I
> would suppose.

That's not entirely correct.  The kernel maintains one entropy pool
along with an estimate of how many bits of entropy actually exist
within it.  Various interrupt events fold entropy into the pool and
increase the estimated number of bits of "random".  Both /dev/random
and /dev/urandom draw their data from this pool, using an algorithm
based on SHA, and both deplete the estimated amount of entropy in the
pool.

When the entropy pool is estimated to be empty (as many bits have come
out as it was estimated went in) /dev/random blocks, but /dev/urandom
does not.  That means that once the pool is depleted /dev/urandom
effectively becomes a pseudo-RNG (and SHA makes for a pretty damn
good, if slow, PRNG).  As more entropy is fed into the pool,
/dev/urandom will use it, it's just that it will happily produce more
pseudo-random output bits than really random input bits to the pool.
(This also means that if you spew data from /dev/urandom for a while,
then access /dev/random it will probably block almost immediately).

SHA is slow enough however, that even though /dev/urandom is not
entropy-limited it will still produce data a lot slower than a hard
disk can write it.

-- 
David Gibson			| For every complex problem there is a
david at gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson