Re: Randomness using computers

On 09/01/2011 06:57, unruh wrote:

Now, /dev/random should not be used except perhaps in very very
special circumstances, not least because it blocks if no "random"
bits are available. This has screwed up numerous programs.

Why did you put "random" in quotes? The intention at least is that the
bits emitted by /dev/random are authentic random bits (to the extent
that the events that feed its entropy pool are authentically random events).

/dev/urandom uses the same kind of randomness but uses a
cryptographically strong hash procedure to generate output bits even
when the input runs out. It does not block, but is almost certainly
impossible to predict.

The input in question being the output of /dev/random.

As long as /dev/random hasn't dried up, the bits you read from
/dev/urandom are exactly as random as the bits from /dev/random. But
each bit drawn from /dev/urandom under these circumstances depletes the
pool, just as if it had been drawn from /dev/random. Then, once the pool
has dried up, /dev/urandom stops producing true random bits, and starts
producing pseudo-random bits, *without any notice*.

So if you need true random bits, you must draw them from /dev/random,
because /dev/urandom might be giving you something else, and you can't
easily tell. If /dev/random has dried up, and you need true random bits,
it follows that you will have to wait; there is no other source of true
random bits, unless you have a hardware RNG on your system (and that
would normally be feeding /dev/random anyway).

But if pseudo-random bits are good enough, then you shouldn't draw them
from /dev/urandom, because if there are true random bits available it
will deplete those bits unnecessarily.

So I can't see what good reason there can ever be to use /dev/urandom.
Instead, if cryptographically-secure pseudo-random bits are required one
should seed a CSPRNG from /dev/random, and use that CSPRNG instead.

I believe much of the problem with "numerous programs" freezing due to
/dev/random drying up results from wasteful use of /dev/urandom. For
example, stack protection in recent versions of glibc Linuces draws 64
bits from /dev/urandom every time a process starts. These bits don't
need to be cryptographically secure at all.

--
MrD.

.