Messages in this thread | | | Date | Mon, 19 Aug 2002 09:02:07 -0500 | From | Oliver Xymoron <> | Subject | Re: 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |