[Python-ideas] PEP 504: Using the system RNG by default

[Tim Peters]

[Stephen J. Turnbull <stephen at xemacs.org>]
>>> (2) ISTM there are no likely attack vectors due to choice of default
>>>     RNG in random.random, based on Tim's analysis, but AFAICS he's
>>>     unwilling to say it's implausible that they exist.  (Sorry for the
>>>     double negative!)  I take this to mean that there may be real risk.

[Tim]
>> Oh, _many_ attacks are possible.  Many are even plausible.  For
>> example, while Python's _default_ seeding is based on urandom()
>> setting MT's entire massive state (no more secure way exists), a user
>> making up their own seed is quite likely to do so in a way vulnerable
>> to a "poor seeding" attack.

[Stephen]
> I'm not sure what you mean to say,

That the most obvious and easiest of RNG attacks remain possible
regardless of anything that may be done, short of refusing to provide
a seedable generator.


> but I don't count that as "due to choice of default RNG".  That's foot-
>shooting of the kind we can't do anything about anyway, and if *that*
> is what Nick is worried about, I'm worried about Nick. ;-)

Oh no, _nobody_ is worried enough to "do something" about it.  Not really.

Note that in the PHP paper, 10 of the 16 apps scored "full attack" via
pure brute force against poor seeding (figure 13, column 4.3).  That's
probably mostly due to that the versions of PHP tested inflicted poor
_default_ seeding on users.  I hope so.  But there's no accounting of
which apps did and didn't set their own seeds.  They did note that
"Joomla" attempted to repair a security bug by _removing_ its own
seeding, in 2010.  Which left it open to PHP's poor default seeding
instead - which was nevertheless an improvement.


> *I* am more worried about attacks we don't know about yet (or at least
> haven't been mentioned in this thread), and maybe even haven't been
> invented yet.  I presume Nick is, too.

Fundamentally, I just don't see the sense in saying that someone who
does their own seeding deserves whatever they get, while someone who
uses an inappropriate generator in a security context should be saved
from themself.  I know, I read all the posts about why I'm wrong.  I
just don't buy it.  There's no real substitute for understanding what
you're doing, regardless of field.  Yes, incompetence can cause great
damage.  But I'm not sure it does the world a real favor to possibly
help a programmer incompetent to do a task keep working in the field a
little longer.  This isn't the only damage they can cause, and the
longer they keep working in an area they don't understand the more
damage they can do.  The alternative?  Learn how to use frickin'
SystemRandom.  It's not hard.  Or get work for which they are
competent.


>> "Password generators" should be the least of our worries.  Best I can
>> tell, the PHP paper's highly technical MT attack against those has
>> scant chance of working in Python except when random.choice(x) is
>> known to have len(x) a power of 2.

> That's genuinely comforting to read (even though it's the second or
> third time I've read it ;-)

If you read everything I ever wrote, it's the second.

Although you may have _inferred_ it before I ever wrote it, from
Nathaniel's "if I use the base64 or hex alphabets", instinctively
leaping from "hmm ... 2**6 and ... 2**4" to "power of 2".  In which
case it could feel like the third time.

And I used the phrase "power of 2" in a reply to you before, but in a
context wholly unrelated to the PHP paper.  That may even make it feel
like the fourth time.

Always happy to clarify ;-)


> But I'm still nervous about the unknown.

Huh!  I've heard humans are prone to that.  In which case, there will
always be something to be nervous about :-)