[Cryptography] randomness +- entropy

[John Denker]

On 11/11/2013 10:30 PM, James A. Donald wrote:
> Obviously what we need is something that blocks until it has
> accumulated 128 bits of entropy, generates pseudo random output from
> its existing state, and never blocks thereafter.  From time to time,
> not very often at all, it reseeds by adding an addtional 128 bits of
> entropy all at once.
> 
> However, people complain that if any of the existing sources of
> randomness are fixed to work like that, it is not bug compatible and
> will break existing software.
> 
> So:  Create a new source of randomness, xrandom, which is like
> urandom, except for the bug.

Sorry, the problem is muuuuch harder than that.  If the solution
were that simple and that obvious, it would have been implemented
a long time ago.

The fact is, there are some applications that cannot make do with
low-quality randomness *and* cannot afford to wait.

  -- A PRNG that puts out low-quality randomness causes insidious
   failures.
  -- A PRNG that blocks causes manifest failures.

It could be argued that trading an insidious failure for a manifest
failure is a step in the right direction, but it is only a small
step, and it does not solve the main problem.

We need a PRNG that /always/ puts out a cryptographically-strong
random distribution ... early in the boot-up process and at all
times thereafter.  Specific constructive suggestions for how to
do this have been put forward ... such as putting a seed in the
kernel boot image, and making sure the seed is properly provisioned.

If/when we have a PRNG that is always ready to use, the question 
of blocking does not arise, and there is no need to define a new 
interface.