> Am Montag, 19. August 2002 12:15 schrieb Marco Colombo:
> > On Mon, 19 Aug 2002, Theodore Ts'o wrote:
> >
> > [...]
> >
> > > P.S. /dev/urandom should probably also be changed to use an entirely
> > > separate pool, which then periodically pulls a small amount of entropy
> > > from the priamry pool as necessary. That would make /dev/urandom
> > > slightly more dependent on the strength of SHA, while causing it to
> > > not draw down as heavily on the entropy stored in /dev/random, which
> > > would be a good thing.
> >
> > Shouldn't it be moved to userpace, instead? Pulling a small amount
> > of entropy from /dev/random can be done in userspace, too. And the
>
> 1. You create a problem for in kernel users of random numbers.
> 2. You forgo the benefit of randomness by concurrent access to /dev/urandom
> 3. You will not benefit from hardware random number generators as easily.
You lost me. The kernel of course has "client" access to the internal
pool. And since the userspace reads from /dev/random, it benefits
from HRNG just the same way it does now. Point 2 is somewhat obscure
to me. The kernel has only one observer to deal with, in theory.
One that gains *all* the knowlegde about the internal pool the
kernel leaks, mainly by returning random bits to those who ask. Assuming
the observer has less than 100% knowledge of that is just overstimating
the entropy (== understimating the ability of the observer to guess
the internal state). And from the application standpoint, it could just
discard part of the values it gets from the PRNG, to emulate concurrent
access, but what for? The result is as good as the untouched PRNG
sequence...
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
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/