[issue27272] random.Random should not read 2500 bytes from urandom

[Tim Peters]

Tim Peters added the comment:

> Searching github pulls up a number of results of people
> calling it, but I haven't looked through them to see
> how/why they're calling it.

Sorry, I don't know what "it" refers to.  Surely not to a program exposing the output of .getstate()?!

Regardless, there was a long discussion about the `secrets` module at the time, and nobody found any real code vulnerable to the approaches in the PHP paper under Python 3 (contrived code, certainly - that's easy).  Again, exploiting lame seeding alone sufficed to crack most of their examples, and Python's use of urandom() for seeding eliminated that approach (in Python 2 too).  

Examples potentially vulnerable to state equation-solving were "just like" what the PHP coders rolled by hand:  uses of things like .choice() and .randrange() to build "random" strings (passwords, session tokens, ...), from relatively small alphabets.  The smaller the alphabet, the more resistant Python 3 is to this approach, because the more likely ._randbelow() will invisibly skip over MT outputs.

For a while an incorrect claim was mistakenly accepted:  that when len(alphabet) was a power of 2, choice(alphabet) made an always-known number of MT calls.  If that were true, the equation solver could deduce the state quickly in such cases, which are relatively common.  But it's false - ._randbelow() is actually _most_ likely to skip over MT outputs when it's making a choice from a power-of-2 number of possibilities.  That's not obvious from a glance at the code.

I remain -1 on making seeding "dumb" again.  But I don't care whether urandom() returns low-quality bytes in the boot-time edge cases people are upset about.  They're still likely to be "better" than anything spun out of stuff like time.time().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27272>
_______________________________________