> > > True, although that only gives you a single bit of information, not
> > > the entire queue depth.
> >
> > I don't see how that makes a difference. Either /dev/urandom
> > is providing entropic bytes, or it isn't.
>
> Well, that is true; and I guess if you wanted to you could drain the
> queue by doing nonblocking reads on /dev/random. Hence it probably
> *wouldn't* be an (additional) security hole (except the covert
> channel, but Linux makes no attempt at eliminating covert channels --
> it provides IPC instead :) to allow anyone to read the enthropy pool
> size.
to defeat pool-draining attacks, what about this solution:
- 'reserved entropy', only for priviledged code (root currently)
- exposing only the blocking device to nonpriviledged code.
user-space needs entropy only for things like PGP key generation or SSH
key generation, so these restrictions do not look like to be a problem,
and IMO they defeat all user-space pool-draining attacks.
Normally the pool is full. A daemon could monitor the size of the pool and
start disk or networking activities automatically, when it's getting too
small. (but this is only for convenience, not strictly necessary to have a
safe entropy pool)
-- mingo