Hello Paul and others listening, > I'm puzzled as to why, in this day and age, shred (and any other > programs that might need lots of hard-to-guess random numbers) needs > to have its own random number generator. Why can't such programs just > read /dev/urandom? Is it because they need to fall back on something > on hosts that lack /dev/urandom?
there may be several reasons, but one thing needs some clarification: /dev/urandom does *not* provide high quality pseudo-random numbers, since they depend on the kernel's entropy pool - if there isn't enough entropy present, /dev/urandom does provide pseudo-random numbers, which may be vulnerable - therefore /dev/random does exist, but /dev/random simply waits, until the entropy pool has gathered enough bits for producing good quality pseudo-random numbers. In case many commands do read /dev/urandom, the generated numbers could get very lousy - but even using /dev/random is of no help, since it could take a very long time, until the system has gathered enough entropy on systems, which aren't running for months with heavy `cron' and typing activity. Surely most commands don't need high quality pseudo-random numbers, so a local pseudo-random number generator is the fastest way of producing some more or less randomness needed, since a simple function/library call is faster than calling a kernel function, which adds up a lot, if many such values are needed. As far as some shuffled input lines are concerned, there's no need for high quality pseudo-random numbers, so a library function (or a local generator) seeded with the actual time combined with the running pid delivers more than enough randomness for this case - and remains fast in execution. IHMO it's counter-productive these days, if each and every command, which needs just a handful of pseudo-random values for no special reason as only to provide some variations of output, is reading /dev/urandom and takes away good quality pseudo-random values from those commands, really needing them. (just a thought of mine, but maybe discussable?) Even if considering `shred' (or the various wipe tools available), there is mostly no need for good randomness, or even randomness at all, since Peter Gutmann's 27-pass algorithm with static values showed, that files could be deleted safely, making it very hard to nearly impossible to recover the previous data on the underlying disk, without the need of even one random byte... THX for listening. CU Tom. (Thomas M.Ott) Germany _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
