[148130] in cryptography@c2.net mail archive
Re: [Cryptography] randomness +- entropy
daemon@ATHENA.MIT.EDU (James A. Donald)
Tue Nov 12 01:25:01 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 12 Nov 2013 15:30:18 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <17FC4534-EF1D-4572-9891-75E071C60869@gmail.com>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 2013-11-12 05:38, John Kelsey wrote:
> On Nov 10, 2013, at 9:27 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> ...
>> The main reason why most application programs tend not to want to use
>> /dev/random is precisely because it will block --- but if you want
>> hard randomness, and the system doesn't have any, what else can you
>> do?
>
> I can't think of many times when it's really appropriate to demand full entropy, rather than cryptographically secure bits. It seems like having /dev/urandom be capable of *either* generating cryptographically secure bits *or* generating predictable bits forces application developers into either using /dev/random or crossing their fingers and using /dev/urandom. And if lots of people are being security-conscious, they all have to use /dev/random, and it will block for a really long time.
>
> If you imagine a choice between:
>
> a. A secure cryptographic PRNG (say CTR_DRBG using AES256) which is catastrophically reseeded whenever it's convenient and the entropy pool is assessed at more than 256 bits. (The pool is then reset to 0.)
>
> b. /dev/urandom and /dev/random as they are now.
>
> I'm not clear on what situations there are where (b) provides better practical security than (a).
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.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
