[Python-ideas] Should our default random number generator be secure?

[Tim Peters]

[Stefan Krah <skrah at bytereef.org>]
> I can't find much at all when searching for "chacha20 equidistribution".
> Contrast that with "mersenne twister equidistribution" and it seems that
> chacha20 hasn't been studied very much in that respect (except for
> the pcg-random site).
>
> So I also think this should preclude us from replacing the current
> random() functions.

Well, most arguments about random functions rely on fantasies ;-)  For
example, yes, the Twister is provably equidistributed to 32 bits
across 623 dimensions, but ... does it make a difference to anything?
That's across the Twister's _entire period_, which couldn't actually
be generated across the age of the universe.

What may really matter to an application is whether it will see rough
equidistribution across the infinitesimally small slice (of the
Twister's full period) it actually generates.  And you'll find very
little about _that_ (last time I searched, I found nothing).  For
assurances about that, people rely on test suites developed to test
generators.

The Twister's provably perfect equidistribution across its whole
period also has its scary sides.  For example, run random.random()
often enough, and it's _guaranteed_ you'll eventually reach a state
where the output is exactly 0.0 hundreds of times in a row.  That will
happen as often as it "should happen" by chance, but that's scant
comfort if you happen to hit such a state.  Indeed, the Twister was
patched relatively early in its life to try to prevent it from
_starting_ in such miserable states.   Such states are nevertheless
still reachable from every starting state.

But few people know any of that, so they take "equidistribution" as
meaning a necessary thing rather than as an absolute guarantee of
eventual disaster ;-)

What may really matter for most simulations is that the Twister never
reaches a state where, in low dimensions, k-tuples fall on "just a
few" regularly-spaced hyperplanes forever after.  That's a systematic
problem with old flavors of linear congruential generators.  But that
problem is _so_ old that no new generator proposed over the last few
decades suffers it either.


> Adding an arc4random module with the caveat that its quality will
> be as good as the current OpenBSD libcrypto/libressl(?) would be okay.

Anyone is welcome to supply such a module today, and distribute it via
the usual channels.

Python already supplies the platform spelling of `urandom`, and a very
capable random.SystemRandom class based on `urandom`, for those
needing crypto-strength randomness (relying on what their OS believed
that means, and supplied via their `urandom`).

Good enough for me.  But, no, I'm not a security wonk at heart.