[Python-ideas] PEP 504: Using the system RNG by default
Stephen J. Turnbull
stephen at xemacs.org
Wed Sep 16 04:22:58 CEST 2015
A pseudo-randomly selected recent quote:
> It would never occur to me to reach for the random module if I want
> to do cryptography.
It's sad that so many of the opponents of this change make this kind
of comment sooner or later. Security is (rarely) about *any* of *us*!
Most of *us* don't need it (if we do, our physical or corporate
security has already been compromised), most of *us* understand it, a
somewhat smaller fraction of *us* behave in habitually secure ways (at
the level we practice oral hygiene, say).
That doesn't mean that security has to be #1 always and everywhere in
designing Python, but I find it pretty distressing that apparently a
lot of people either don't understand or don't care about what's at
stake in these kinds of decisions *for the rest of the world*.
The reality is that security that is not on by default is not
secure. Any break in a dike can flood a whole town.
The flip side is that security has costs, specifically the
compatibility break, and since security needs to be on by default, the
aggregate burden should be *presumed large* (even a small burden is
spread over many users). Nevertheless, I think that the arguments to
justify this change are pretty good:
(1) The cost of adapting per program seems small, and seems to restricted
to a class of users (software engineers doing regression testing
and scientists doing simulations) who probably can easily make the
change locally. Nick's proto-PEP is specifically designed so that
there will be no cost to naive users (kids writing games etc) who
don't need access to state.
Caveat: there may be a performance hit for some naive users. That
can probably be avoided with an appropriate choice of secure RNG,
but that hasn't actually been benchmarked AFAIK.
(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.
(3) The anecdotal evidence that the module's current default is
frequently misused is strong (the StackOverflow recipes for
Two out of three ain't bad. YMMV, of course.
More information about the Python-ideas