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

[Guido van Rossum]

On Sat, Jun 11, 2016 at 2:16 PM, Donald Stufft <donald at stufft.io> wrote:

>
> On Jun 11, 2016, at 4:48 PM, Guido van Rossum <guido at python.org> wrote:
>
> But I find an os.getrandom() that only exists on those (few?) platforms
> that support it a nuisance too -- this just encourages cargo cult code
> that's unnecessarily complicated and believed to be secure without anybody
> ever verifying.
>
>
>
> Well, new enough Linux has getrandom(0), OpenBSD has getentropy(), Solaris
> has getrandom(), Windows has CryptGenRandom which all make it possible (or
> it’s the only way to invoke it) to get cryptographically secure random
> bytes or block and no in-between. So it’d likely be possible to have
> os.getrandom() with blocking semantics and no FD on all of the most popular
> platforms we support.
>
> If we relax the no FD then FreeBSD and OS X also have /dev/random (or
> /dev/urandom it’s the same thing) which will ensure that you give
> cryptographically secure random bytes.
>

OK, so we should implement the best we can do for the secrets module, and
leave os.urandom() alone. I think the requirement that the secrets module
remain pure Python has to be dropped. I'm not sure what it should do if
even blocking can't give it sufficiently strong random bytes, but I care
much less -- it's a new API and it doesn't resemble any OS function, so as
long as it is documented it should be fine.

An alternative would be to keep the secrets module linked to SystemRandom,
and improve the latter. Its link with os.random() is AFAIK undocumented.
Its API is clumsy but for code that needs some form of secret-ish bytes and
requires platform and Python version independence it might be better than
anything else. Then the secrets module is just what we recommend new users
on Python 3.6.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160611/a0a7e83d/attachment-0001.html>