Re: Problem with random.c and PPC

[Oliver Xymoron]

On Mon, Aug 19, 2002 at 11:29:00AM +0200, Marco Colombo wrote:
> On Sat, 17 Aug 2002, Oliver Xymoron wrote:
> 
> > > 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.
> 
> How can you make /dev/urandom return something without leaking
> information about the internal pool state to the observer?
> Do you plan to switch to a completely different source and reseed the
> PRNG with data not taken from the pool?

I plan to make a third pool, reseeding from the first. The code
appears to actually be structured with that in mind, it just hasn't
been done.

> In my experience, there's little you can do when the entropy demand is
> higher than the rate at which the kernel collects it. Either we implement
> /dev/random quotas, or it will be always easy to drain the internal pool
> from userspace.

Root can decide, for instance, to make /dev/random privileged to some
group if important_set is getting starved by unimportant_set.

> I'd say that /dev/urandom interface is somewhat broken: the application
> either can live with an almost pure PRNG (and use an userspace
> implementation) or needs true, pure and strong randomness. The programmer
> should know the mimimal need for true randomness of the application.
> For every application that uses /dev/urandom, it's 0 by definition of
> /dev/urandom, and the application should just use an userspace PRNG.

Many actually do this. I believe OpenSSL merely seeds though I'd have
to doublecheck.  

> If you need a weak solution (a perturbated PRNG), just read a few bits
> from /dev/random at times (but in a controlled and defined way).

It might be helpful to think of /dev/urandom as akin to /dev/random with
O_NONBLOCK. "Give me stronger bits if you got 'em" is desirable,
otherwise this thread would be much shorter.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."