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

Cory Benfield cory at lukasa.co.uk
Fri Sep 11 16:34:55 CEST 2015

On 11 September 2015 at 13:56, M.-A. Lemburg <mal at egenix.com> wrote:
> The random module seeds its global Random instance using urandom
> (if available on the system), so while the generator itself is
> deterministic, the seed used to kick off the pseudo-random series
> is not. For many purposes, this is secure enough.

Secure enough for what purposes? Certainly not generating a password,
or anything that is 'password equivalent' (e.g. session cookies).

As you acknowledge in the latter portion of your email, one can
predict the future output of a Mersenne Twister by observing lots of
previous values. If I get to see the output of your RNG, I can
dramatically constrain the search space of other things it generated.
It is not hard to see how you can mount a pretty trivial attack
against web software using this,

> It's also easy to make the output of the random instance more
> secure by passing it through a crypto hash function.

Or...just use a CSPRNG and save yourself the computation overhead of
the hash? Besides, anyone who knows enough to hash their random
numbers surely knows enough to use a CSPRNG, so who does this help?

> Perhaps it's time to switch to a better version of MT, e.g.
> a 64-bit version (with 64-bit internal state):
>     http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html
> or an even faster SIMD variant with better properties and
> 128 bit internal state:
>     http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html
> Esp. the latter will help make brute force attacks practically
> impossible.

Or, we can move to a CSPRNG and stop trying to move the goalposts on
MT? Or, do both? Using a better Mersenne Twister does not mean we
shouldn't switch the default.

More information about the Python-ideas mailing list