Re: Plentiful unpredictable randomness

[<Paul.Koning%dell.com@localhost>]

> On Jul 22, 2019, at 8:17 AM, Andreas Gustafsson <gson%gson.org@localhost> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> Taylor R Campbell wrote:
>> It has become popular to redefine the traditional semantics of
>> /dev/random or /dev/urandom so that one or both will block once at
>> boot until the OS thinks the entropy pool may have been seeded, and
>> then never block again.
> 
> IMO, those are the most useful semantics for a /dev/*random device,
> and NetBSD ought to provide a device that works this way.
> 
> This would combine the advantages of the existing /dev/random and
> /dev/urandom by providing randomness that is both unpredictable (like
> /dev/random) and plentiful (like /dev/urandom) once seeded.  It would
> not solve the problem of /dev/random blocking forever when a system
> has no entropy available at all, but it would solve the more common
> problem of it blocking due to becoming "exhausted" from use.

Yes.  It's a good idea to study the modern literature of cryptographic random number generators for this issue.

The fundamental requirement of a crypto RNG is that you can't predict (in the sense of "better than a 50/50 guess") any bit of the output stream given all the other bits of the stream.  That translates into a mathematical property of "indistinguishable from a random process", which is one of the modern tests for good ciphers.  Given the birthday paradox, a stream generated by a good cipher is likely to be distinsguishable from a random process after about 2^sqrt(block size) bits, so, for example, a RNG built around SHA-256 should not be used to generate more than 2^128  bits before reseeding.

But apart from that, given that the underlying machinery is built correctly, enough seed bits will make the initial state unpredictable, and the cipher will make all the remaining bits up to the limit unpredictable.  That translates to the "block once" property you described as desirable.

Maybe NetBSD needs an algorithm upgrade for the /dev/random core, or maybe the current one is adquate; I haven't studied that.  I'm also not a cryptographer; the above comments are about at the limit of my knowledge.

	paul