[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[Cory Benfield]

Cory Benfield added the comment:

> Those say that if you call getrandom(GRND_NONBLOCK) before the entropy
> pool has been initialized, it will return EAGAIN, but any time you read
> from /dev/urandom you will always get random data.


Yeah, so this is why the crypto folks were all up in arms about falling back to the /dev/urandom behaviour on Linux: Linux's /dev/urandom behaviour is really pretty dangerous.

In essence, on Linux, /dev/urandom will *always* return you some bytes, and their actual quality is entirely uncertain. This means that fundamentally without interrogating the kernel state before you read, you can't really be sure that /dev/urandom is safe for what you want it to be safe for.

But /dev/random isn't a suitable replacement in most cases, because /dev/random goes too far the other way: it has this hyper-paranoid notion about "entropy" that isn't really well-founded, and so sometimes it'll go on strike for a while.

This is why we've been pushing to keep hold of the os.urandom() implementation that CPython 3.5 now has: it irons out one of the most annoying warts in Linux RNGs. As Ted Tso has said elsewhere in this thread, /dev/urandom only exhibits its current behaviour for backward compatibility reasons: getrandom(flags=0) is really the ideal behaviour for almost any case *except* what Python is doing at startup.

Not that it needs saying again, but I'm still in favour of doing something like what Christian is suggesting, or like I suggested earlier (have os.urandom remain good, have Python internally fall back to weaker seeds for random and SipHash if it's run so early that the system hasn't started up fully yet).

----------

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