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

[Larry Hastings]

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 
/dev/urandom.


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)
    else:
         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.


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