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

Christian Heimes christian at python.org
Sat Jun 11 08:40:45 EDT 2016

On 2016-06-10 20:42, Chris Jerdonek wrote:
> On Fri, Jun 10, 2016 at 11:29 AM, David Mertz <mertz at gnosis.cx> wrote:
>> This is fairly academic, since I do not anticipate needing to do this
>> myself, but I have a specific question.  I'll assume that Python 3.5.2 will
>> go back to the 2.6-3.4 behavior in which os.urandom() never blocks on Linux.
>> Moreover, I understand that the case where the insecure bits might be
>> returned are limited to Python scripts that run on system initialization on
>> Linux.
>> If I *were* someone who needed to write a Linux system initialization script
>> using Python 3.5.2, what would the code look like.  I think for this use
>> case, requiring something with a little bit of "code smell" is fine, but I
>> kinda hope it exists at all.
> Good question.  And going back to Larry's original e-mail, where he said--
> On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings <larry at hastings.org> wrote:
>> ...
>> The issue author had already identified the cause: CPython was blocking on
>> getrandom() in order to initialize hash randomization.  On this fresh
>> virtual machine the entropy pool started out uninitialized.  And since the
>> only thing running on the machine was CPython, and since CPython was blocked
>> on initialization, the entropy pool was initializing very, very slowly.

I repeat for like the fifth time:

os.urandom() and Python startup are totally unrelated. They just happen
to use the same internal function to set the hash randomization state.
The startup problem can be solved without f... up the security
properties of os.urandom().

The correct questions to ask are:

1) Does hash randomization for bytes, text and XML always require
cryptographically strong random values from a potentially blocking CPRNG?

2) Does the initial state of the Mersenne-Twister of the default
random.Random instance really need cryptographically strong values?

3) Should os.urandom() always use the best CSPRNG source available and
make sure it never returns weak, predictable values (when possible)?

The answers are:

1) No
2) No

If you think that the answer to 3 is "No" and that a CSPRNG is permitted
to return predictable values, then you are *by definition* ineligible to
vote on security issues.


More information about the Python-Dev mailing list