> On Jul 21, 2019, at 3:20 PM, Taylor R Campbell
> <campbell+netbsd-tech-k...@mumble.net> wrote:
>
>
> [EXTERNAL EMAIL]
>
>> Date: Sun, 21 Jul 2019 20:52:52 +0200
>> From: Manuel Bouyer <bou...@antioche.eu.org>
>>
>> /dev/randon actually works as documented and if rust wants /dev/urandom
>> behavior it should use /dev/urandom. Also I'd like to get explained why
>> a compiler needs that much random bits.
>
> The difference is that /dev/random may block, and if it blocks, it
> doesn't wake up until the entropy pool is seeded. In contrast,
> /dev/urandom never blocks, even if the entropy pool has not yet been
> seeded.
>
> There is no reason in modern cryptography to read more than one byte
> from /dev/random ever in a single application; once you have done
> that, or confirmed some other way that the the entropy pool is seeded,
> you should generate keys from /dev/urandom.
The way I see it:
/dev/random blocks until it has adequate entropy to deliver cryptographically
strong random numbers. Once unblocked it delivers such random numbers.
/dev/urandom is equivalent to /dev/random if there is adequate entropy, but it
will also deliver random numbers not suitable for cryptography before that time.
In addition, the notion of "entropy being consumed" is obsolete (if it was ever
valid), so once adequately seeded /dev/random should not block after that.
Do we have an implementation that does these things? It's critical to have a
good implementation of /dev/random, otherwise you can't run security products.
paul
