[148135] in cryptography@c2.net mail archive
Re: [Cryptography] randomness +- entropy
daemon@ATHENA.MIT.EDU (John Denker)
Tue Nov 12 15:29:34 2013
X-Original-To: cryptography@metzdowd.com
Date: Mon, 11 Nov 2013 23:44:16 -0700
From: John Denker <jsd@av8n.com>
To: jamesd@echeque.com, cryptography@metzdowd.com,
RNG mlist <rng@lists.bitrot.info>
In-Reply-To: <5281BCEA.509@echeque.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography