[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
larry at hastings.org
Thu Jun 9 18:33:03 EDT 2016
On 06/09/2016 10:22 AM, Donald Stufft wrote:
>> On Jun 9, 2016, at 1:14 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> Just to be clear, this is only an option on Linux, right? All the other
>> major platforms block, whatever we decide to do on Linux. Including
> To my knowledge, all other major platforms block or otherwise ensure that /dev/urandom can never return anything but cryptographically secure random. 
I've done some research into this over the past couple of days. To the
best of my knowledge:
* Linux: /dev/urandom will never block. If the entropy pool isn't
initialized yet, it will return poor-quality random bits from what is
effectively an unseeded PRNG. (Yes: it uses a custom algorithm which
isn't considered CPRNG-strength, it is merely a PRNG seeded with entropy.)
* OS X: AFAICT, /dev/urandom guarantees it will never block. It uses an
old CSPRNG, 160-bit Yarrow. The documentation states that if the
entropy pool is "drained", it won't block; instead it'll degrade
("output quality will suffer over time without any explicit indication
from the random device itself"). It isn't clear how initialization of
the entropy pool during early startup might affect this.
* FreeBSD: /dev/urandom may block. It also using Yarrow (but maybe with
more bits? and possibly switching soon to Yarrow's successor,
Fortuna?). Both devices guarantee high-quality random bits, and will
block if they feel like they're running low on entropy.
* OpenBSD 5.1 is like FreeBSD, except the algorithm used is ARC4. In
OpenBSD 5.5 they changed to using ChaCha20.
On all of those platforms *except* Linux, /dev/random and /dev/urandom
are exactly the same.
Also, regarding Windows: Victor Stinner did some experiments with a VM,
and even in early startup he was able to get random bits from
os.urandom(). But it's hard to have a "fresh" Windows VM, so it's
possible it had residual entropy from a previous boot, so this isn't
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev