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

[Steven D'Aprano]

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