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

[Donald Stufft]

> On Jun 9, 2016, at 12:30 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
>> 
>> os.urandom
>> ----------
> [...]
>> With that in mind, I think that we should, to the best of our ability given the
>> platform we're on, ensure that os.urandom does not return bytes that the OS
>> does not think is cryptographically secure.
> 
> Just to be clear, you're talking about having it block rather than raise 
> an exception, right?
> 
> If so, that makes sense to me. That's already the behaviour on all major 
> platforms except Linux, so you're just bringing Linux into line with the 
> others. Those who want the non-blocking behaviour on Linux can just read 
> from /dev/urandom.


There are three options for what do with os.urandom by default:

* Allow it to silently return data that may or may not be cryptographically secure based on what the state of the urandom pool initialization looks like.
* Raise an exception if we determine that the pool isn’t initialized enough to get secure random from it.
* Block until the pool is initialized.

Historically Python has done the first option on Linux (but not on other OSs) because that was simply the only interface that Linux offered at all. In 3.5.0 Victor changed the way os.urandom worked in a way that made it use the third option (he wasn’t attempting to change the security properties, just avoid using an FD, but it improved the security properties as well).

My opinion is that blocking is slightly better than raising an exception because it matches what other OSs do, but that both blocking and raising an exception is better than silently giving data that may or may not be cryptographically secure.

—
Donald Stufft