Tim Peters added the comment:

Donald, your script appears to recreate the state from some hundreds of 
consecutive outputs of getrandbits(64).  Well, sure - but what of it?  That 
just requires inverting the MT's tempering permutation.  You may as well note 
that the state can be recreated from the output of random.getstate() - in which 
case, your script could be a lot shorter too ;-)

But that's not what real-life programs expose.  All the flaws in the PHP paper 
related to deducing PRNG state were found in real-life code using idiomatic PHP 
ways of spelling choice() or randrange(), with relatively few possible outputs.

Produce a program that can deduce the state, in Python 3, from - say - a 
million consecutive outputs of randrange(256), and _that_ would be interesting, 
because that would be relevant.  It's easy in Python 2.  But in Python 3, you 
can't tell from the outputs how many times MT was invoked under the covers 
(but, of course, you can from your contrived getrandbits(64) outputs - the 
C-level MT is called exactly twice for each of those outputs).

In any case, the vast bulk of the PHP flaws were found by out-brute-forcing 
dumb PRNG initialization, which requires nothing in the way of reproducing 
state via reverse-engineering outputs (see Figure 13).  Noting that idiomatic 
use of Python 3's choice() (etc) is resistant to the paper's equation-solving 
state-deducing approach is really just a footnote - the _point_ is that lame 
seeding is, all by itself, a Bad Idea.  That alone was enough to crack most of 
the PHP programs the paper covered.

As to the rest, there are already too many massive bug reports arguing about 
urandom()-in-general.  The title of _this_ bug report suggested it may be good 
enough to reduce the _number_ of urandom() bytes MT initialization uses.  But, 
so far, Victor & I appear to be the only ones who made an on-topic comment 
about that ;-)

What do you believe?  For example, do you believe it would remain a disaster if 
MT initialization wanted only 1 byte from urandom()?  Or is 0 the only value 
you can live with?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27272>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to