[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