[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Cory Benfield]

Cory Benfield added the comment:

I have never seen it block in person, but I also wouldn't expect to. OS X's blocking guarantees are the same as FreeBSD's: that is, both /dev/random and /dev/urandom block until sufficient entropy has been gathered at startup and then never block again.

This means that, on OS X, in practice, /dev/urandom does never block, because you basically can't run user code early enough to encounter this problem.

FreeBSD again has the exact same behaviour: /dev/urandom is a symlink to /dev/random, and both will block at startup until sufficient entropy is gathered and never again. This is the bigger risk for Python, because if Linux people want to use Python in their init system it's not unreasonable for FreeBSD folks to want to do it too.

This is why I'm concerned about this "solution": while there's no question that adding getrandom() made the situation worse on Linux, it has drawn our attention to the fact that Python is relying on Linux-only semantics of /dev/urandom on all Unices. That's probably not a good plan.

(The above is all facts. Everything in these parentheticals is opinion. Please disregard as appropriate.

I agree with the OS X devs in that I believe their implementation *is* better than Linux's: sorry Ted! There is no reason to be concerned about using a good kernel CSPRNG once sufficient entropy has been gathered *once*. The CSPRNG essentially "stretches" the entropy out into a long sequence of numbers, much like a cipher like AES "stretches" the entropy in the key across the entire cipherstream. Talking about "running out" of entropy in one of these devices is weird to me: as a blog post linked earlier mentions, it's like talking about "running out of key" in an encryption algorithm.

It seems to me, then, that Linux's /dev/random is wrong in most situations (because it sometimes blocks), and /dev/urandom is wrong in some situations (because it'll run before it has enough entropy to properly seed the CSPRNG and it won't tell you that that is what has happened). On OS X, the best of both worlds occurs: you get no random numbers until sufficient entropy has been gathered to seed the CSPRNG, and then you get good random numbers from that point on.

Please note: I am not a trained cryptographer. However, trained cryptographers have agreed with this set of sentiments, so I think I'm on pretty good ground here.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________