[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
larry at hastings.org
Thu Jun 9 18:22:35 EDT 2016
On 06/09/2016 08:52 AM, Guido van Rossum wrote:
> That leaves direct calls to os.urandom(). I don't think this should
> block either.
Then it's you and me against the rest of the world ;-)
Okay, it's decided: os.urandom() must be changed for 3.5.2 to never
block on a getrandom() call. It's permissible to take advantage of
getrandom(GRND_NONBLOCK), but if it returns EAGAIN we must read from
It's already well established that this will upset the cryptography
experts. As a concession to them, I propose adding a simple!
predictable! function to Python 3.5.2: os.getrandom(). This would be a
simple wrapper over getrandom, only available on platforms that expose
it. It would provide a way to use both extant flags, GRND_RANDOM and
GRND_NONBLOCK, though possibly not exactly mirroring the native API.
This would enable cryptography libraries to easily do what (IIUC) they
regard as the "correct" thing on Linux for all supported versions of Python:
if hasattr(os, "getrandom"):
bits = os.getrandom(n)
bits = os.urandom(n)
I'm not excited about adding a new function in 3.5.2, but on the other
hand we are taking away this functionality they had in 3.5.0 and 3.5.1
so only seems fair. And the implementation of os.getrandom() should be
very straightforward, and its semantics will mirror the native call, so
I'm pretty confident we can get it solid in a couple of days, though we
might slip 3.5.2rc1 by a day or two.
Guido: do you see this as an acceptable compromise?
Cryptographers: given that os.urandom() will no longer block in 3.5.2,
do you want this?
Pointing out an alternate approach: Marc-Andre Lemburg proposes in issue
#27279 ( http://bugs.python.org/issue27279 ) that we should add two
"known best-practices" functions to get pseudo-random bits; one merely
for pseudo random bits, the other for crypto-strength pseudo random
bits. While I think this is a fine idea, the exact spelling, semantics,
and per-platform implementation of these functions is far from settled,
and nobody is proposing that we do something like that for 3.5.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev