On 11 September 2015 at 13:56, M.-A. Lemburg <mal@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.