Re: Increasing entropy

[<Paul_Koning%Dell.com@localhost>]

On Jun 8, 2012, at 2:15 PM, D'Arcy Cain wrote:

> I have been having entropy issues lately.  In particular, password
> generation takes a long time.  The apg utility usually takes almost
> a minute to run.
> 
> I tried bitstir from pkgsrc which does solve the entropy issue but
> it does so by working the disk a lot.  Besides concerns about lowering
> the life of the drives, it also seems to affect disk access.  Users
> are actually noticing hangups when writing files.  So, it seems that
> I have simply traded on slowdown for another.
> 
> I was wondering if there was a better way to increase entropy on these
> headless servers than running the drives.  One idea that occurred to
> me was to use the pseudo-random generator (/dev/urandom) to feed extra
> entropy to /dev/random.  Would mixing pseudo randomness with real be
> random enough for most purposes?
> 
> I also wonder what is draining entropy so much.  Maybe that's where I
> should be focusing but I don't know how to monitor that.
> 
> -- 
> D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
> http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost

From what I remember from reading Schneier's discussion of this topic (in the 
description of the PRNG he designed), the notion of "draining" entropy does not 
make cryptographic sense.  Instead, what you have in a PRNG is a secure 
bitstring extender, which is seeded with a sufficiently unpredictable 
bitstring.  Yes, it's good to add entropy into the mix when you have some, but 
the security property you're looking for is that, knowing large amounts of 
output from /dev/random, you have no practical way to predict any of the bits 
preceding what you know, nor any of the bits following what you know.  And that 
will be true if the extender is cryptographically secure, and the seed has 
enough entropy that brute force search of the seed space is impractical.

So... If we have a good PRNG in the current /dev/random code, then the thing to 
do is to make /dev/random block ONLY when it doesn't yet have enough seed 
entropy, but never block after that point.

Also, whether our current /dev/random is good or not, stirring /dev/urandom 
into it is a waste of time, because /dev/urandom is simply /dev/random without 
the blocking.

        paul