[Cryptography] Random numbers only once
jsd at av8n.com
Tue Feb 4 22:53:43 EST 2014
On 02/04/2014 05:55 PM, Kevin W. Wall wrote:
>> As for whether or not /dev/random should block, that has already been
>> discussed at length here and elsewhere. However, I think most of us
>> would concede that blocking is better than returning predictable
>> pseudo-random values to the caller.
/dev/random will sometimes block. There is no good
way around this. See further discussion below.
On 02/04/2014 05:59 PM, Watson Ladd wrote:
> But that only justifies blocking exactly once after boot.
No, that's not the right answer in general.
-- We must distinguish between /dev/random from /dev/urandom.
-- We must also distinguish between how things presently are
from how they should be.
There should be no excuse for /dev/urandom blocking, ever.
There should be no excuse for /dev/urandom doing anything
except returning high-quality hard-to-predict pseudo-randomly
This should be adequate for almost all "ordinary" uses.
Note that the for all internal-to-the-kernel purposes, the
linux kernel depends on the PRNG provided by /dev/urandom.
The problem is, due to bad design, bad implementation, and
bad operation, there are lots of scenarios where /dev/urandom
returns low-quality squish. This needs to get fixed, pronto.
Fixing it MUST NOT involve making it block.
In particular, much more attention needs to be paid to the
issue of per-instance /provisioning/. Every piece of hardware
and every instance of a VM guest needs to be provisioned with
a high quality seed. This needs to be done before the PRNG
is used for the first time. Provisioning is part of why I
can say that there should be no excuse for /dev/urandom to
block, not ever, not even the first time.
In contrast, /dev/random should be for wizards only.
It might block. It might block now or later. It might stay
blocked for an arbitrarily long time. Anybody who needs to
use /dev/random needs to understand this.
As we have discussed before: "Most" applications should be
content with high-quality pseudo-randomly distributed numbers.
However, every PRNG needs to be seeded. Therefore at /some/
point there needs to be /some/ actual entropy coming from
somewhere. One can imagine a HRNG without a PRNG but not
This distinction is important and will always be important.
/dev/urandom should be a PRNG.
/dev/random should be a HRNG.
For many years, due to bad design, there has been an excessively
close coupling between /dev/random and /dev/urandom, leading to
needless waste of entropy, needless waste of CPU cycles, and
needless confusion about what these devices are and how they
should be used.
This bad design explains why linux kernels have traditionally
stored a seed (relevant to /dev/urandom) but have not bothered
to store high-quality entropy (relevant to /dev/urandom).
I've been collecting a bunch of FAQs and best practices at
More information about the cryptography