On Aug 17, 2002 02:23 -0500, Oliver Xymoron wrote:
> On Sat, Aug 17, 2002 at 12:05:07AM -0600, Andreas Dilger wrote:
> > On Aug 16, 2002 19:45 -0500, Oliver Xymoron wrote:
> > One of the problems, I believe, is that reading from /dev/urandom will
> > also deplete the entropy pool, just like reading from /dev/random.
> > The only difference is that when the entropy is gone /dev/random will
> > stop and /dev/urandom will continue to provide data.
>
> Yep, this is a longstanding problem. Will look into it and a couple
> other things once I get the my current batch of patches running
> against -current.
Sure.
> BTW, did ttyso ever ACK your last set of random changes or is it safe
> to assume it's unmaintained?
Yes, a while later. I'm sure it wouldn't hurt to post your patches here
before submission, but I don't think you need to funnel them through Ted.
> > If you are in there fixing things, it might make sense to have
> > /dev/urandom extract entropy from the random pool far less often than
> > /dev/random. This way people who use /dev/urandom for a source of
> > less-strong randomness (e.g. TCP sequence numbers or whatever), will
> > not be shooting themselves in the foot for when they need a 2048-byte
> > PGP key, if they are low on entropy sources.
>
> Not sure this is an ideal fix. We might instead have an entropy
> low-water mark (say 1/2 pool size), below which /dev/urandom will not
> deplete the pool. This way when we have ample entropy, both devices
> will behave like TRNGs, with /dev/urandom falling back to PRNG when a
> shortage is threatened.
Well, I can think of a few mechanisms that would work better than a
simple on/off method that you are proposing. The current code will
basically "fill" the urandom pool each time it is depleted, and then
when the entropy is gone it will just go on dumping out data. You
could make urandom only get more entropy each N times through its pool,
or make N a function of the "fullness" of the available entropy. Then
if a system has lots of entropy sources urandom is TRNG, but if not
it will gracefully degrade from TRNG to PRNG without wiping out all
the entropy in the process.
As an alternative, instead of taking poolsize bytes of entropy each
N uses, you could take some small amount of entropy to mix into the
pool slowly.
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:13 EST