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

[Tim Peters]

[M.-A. Lemburg <mal at egenix.com>]
> ...
> If you can come up with a crypto RNG that allows repeating the
> results, I think you'd have us all convinced, otherwise it
> doesn't really make sense to compare apples and oranges,
> and insisting that orange juice is better for you than
> apple juice ;-)

For example, run AES in CTR mode.  Remember that we did something
related on whatever mailing list it was ;-) discussing the PSF's
voting system, to break ties in a reproducible-by-anyone way using
some public info ("news") that couldn't be known until after the
election ended.

My understanding is that ChaCha20 (underlying currently-trendy
implementations of arc4random) is not only deterministic, it even
_could_ support an efficient jumpahead(n) operation.  The specific
OpenBSD implementation of arc4random goes beyond just using ChaCha20
by periodically scrambling the state with kernel-obtained "entropy"
too, and that makes it impossible to reproduce its sequence.  But it
would remain a crytpo-strength generator without that extra scrambling
step.

Note that these _can_ be very simple to program.  The "Blum Blum Shub"
crypto generator from 30 years ago just iteratively squares a "big
integer" modulo a (carefully chosen) constant.  Not only
deterministic, given any integer `i` it's efficient to directly
compute the i'th output.  It's an expensive generator, though
(typically only 1 output bit is derived from each modular squaring
operation).