bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort --random-sort


From: ThMO
Subject: Re: sort --random-sort
Date: Tue, 29 Nov 2005 20:57:36 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]