[lkml]   [2002]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Problem with random.c and PPC
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.."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 13:28    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean