On 06/09/2016 10:22 AM, Donald Stufft wrote:

On Jun 9, 2016, at 1:14 PM, Steven D'Aprano <steve@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