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 <da...@netbsd.org>
> http://www.NetBSD.org/ IM:da...@vex.net
>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
