> > > Counterexample: ftp://koobera.math.uic.edu/pub/software/sigs-0.50.tar.gz
> > > uses a lot of entropy for secret key generation.
> >
> > but it's not at all secret anymore if you drain the pool? i think 'lossy'
> > (nonblocking) entropy generation should go into libc, not into the kernel!
> >
>
> The kernel can do a better job of it, since it has access to all the
> entrophy ever passed through as seed, and since the pool-mixing
> function is there anyway, there is no additional cost.
i rather take 'entropy' as an ordinary resource, ie. a user can get it,
root can get more, what one user gets is the property of that user, etc.
This way the picture is extremely clear: root has reserved entropy, libc
caches 'hard entropy', and provides infinit (weak, nonblocking) entropy
for applications that are not security-critical. Such 'mixing' is then
done on per-process basis.
if you read urandom in a tight loop, you drain the pool completely, and
make the output extremely predictable ... eg TCP sequece number guessing.
wether this view is correct ... dunno.
-- mingo