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

Steven D'Aprano steve at pearwood.info
Sat Jun 11 04:24:42 EDT 2016

On Fri, Jun 10, 2016 at 11:42:40AM -0700, Chris Jerdonek wrote:

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 PROBLEM > ... > 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. it seems to me that you'd want such a solution to have code that causes the initialization of the entropy pool to be sped up so that it happens as quickly as possible (if that is even possible). Is it possible? (E.g. by causing the machine to start doing things other than just CPython?)

I don't think that's something which the Python interpreter ought to do for you, but you can write to /dev/urandom or /dev/random (both keep their own, separate, entropy pools):

open("/dev/urandom", "w").write("hello world")

But of course there's the question of where you're going to get a source of noise to write to the file. While it's (probably?) harmless to write a hard-coded string to it, I don't think its going to give you much entropy.

-- Steve

More information about the Python-Dev mailing list