[Python-ideas] Python's Source of Randomness and the random.py module Redux
Chris Angelico
rosuav at gmail.com
Fri Sep 11 10:57:32 CEST 2015
On Fri, Sep 11, 2015 at 6:08 PM, Petr Viktorin <encukou at gmail.com> wrote:
> I've also thought about this idea. The problem with it is that seed()
> and friends affect a global instance of Random.
> If, after this change, there was a library that used random.random()
> for crypto, calling seed() in the main program (or any other library)
> would make it insecure. So we'd still be in a situation where nobody
> should use random() for crypto.
So library functions shouldn't use random.random() for anything they
know needs security. If you write a function generate_password(), the
responsibility is yours to ensure that it's entropic rather than
deterministic. That's no different from the current situation (seeding
the RNG makes it deterministic) except that the unseeded RNG is not
just harder to predict, it's actually entropic.
In some cases, having the 99% by default is a barrier to people who
need the 100%. (Conflating UCS-2 with Unicode deceives people into
thinking their program works just fine, and then it fails on astral
characters.) But in this case, there's no perfect-by-default solution,
so IMO the best two solutions are: Be great, but vulnerable to an
external seed(), until someone chooses; or have no random number
generation until someone chooses. We know that the latter is a
terrible option for learning, so vulnerability to someone else calling
random.seed() is a small price to pay.
ChrisA
More information about the Python-ideas
mailing list