[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
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