[Cryptography] randomness +- entropy

[James A. Donald]

On 2013-11-12 05:38, John Kelsey wrote:
> On Nov 10, 2013, at 9:27 AM, Theodore Ts'o <tytso at 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.