Re: issue with /dev/random? gets depleted very quick

[Matt Mackall <mpm@selenic.com>]

On Sun, 2009-06-14 at 21:58 +0200, Folkert van Heusden wrote:
> [ /dev/random gets emptied very quickly ]
> ...
> > > > Is this a problem? It really shouldn't be. Everyone should be
> > > > using /dev/urandom anyway. And the anti-starvation threshold guarantees
> > > 
> > > Well, if I understood correctly how /dev/*random works, urandom is fed
> > > by /dev/random. So if there's almost nothing left in the main pool and
> > > urandom demands bits then we have an issue.
> > > Also, if you frequently want to generate keys (thing gpg, ssl), I think
> > > you want bits from /dev/random and not urandom.
> > 
> > There is really no difference.
> > In an ideal world, we could accurately estimate input entropy and thus
> > guarantee that we never output more than we took in. But it's pretty
> > clear we don't have a solid theoretical basis for estimating the real
> > entropy in most, if not all, of our input devices. In fact, I'm pretty
> > sure they're all significantly more observable than we're giving them
> > credit for. And without that basis, we can only make handwaving
> > arguments about the relative strength of /dev/random vs /dev/urandom.
> > So if you're running into /dev/random blocking, my advice is to delete
> > the device and symlink it to /dev/urandom.
> 
> Two questions:
> - if the device gets empty constantly, that means that filling
>   applicaties (e.g. the ones that feed /dev/random from /dev/hwrng or
>   from an audio-source or whatever)

This question appears incomplete. Also, your device is not 'getting
empty'.

> - if we don't know if we're accounting correctly, why doing at all?
>   especially if one should use urandom instead of random

Inertia.

> > Also note that if something in the kernel is rapidly consuming entropy
> > but not visibly leaking it to the world, it is effectively not consuming
> > it.
> 
> Then the counter should not be decreased?

There's no way for us to know. In other words, the counter isn't
terribly meaningful in either direction.

-- 
http://selenic.com : development and support for Mercurial and Linux