[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Larry Hastings]

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
>> Windows?
> To my knowledge, all other major platforms block or otherwise ensure that /dev/urandom can never return anything but cryptographically secure random. [1]

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.  
http://www.manpages.info/macosx/random.4.html

* 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 
conclusive.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160609/e20589df/attachment.html>