[Python-ideas] Should our default random number generator be secure?

Wes Turner wes.turner at gmail.com
Fri Sep 11 18:53:46 CEST 2015



On Fri, Sep 11, 2015 at 11:05 AM, Wes Turner <wes.turner at gmail.com> wrote:

> On Thu, Sep 10, 2015 at 9:07 PM, Stephen J. Turnbull <stephen at xemacs.org>
> wrote:
>> Executive summary:
>> The question is, "what value is there in changing the default to be
>> crypto strong to protect future security-sensitive applications from
>> naive implementers vs. the costs to current users who need to rewrite
>> their applications to explicitly invoke the current default?"
> * [ ] DOC: note regarding the 'pseudo' part of pseudorandom and MT
>   * https://docs.python.org/2/library/random.html
>   * https://docs.python.org/3/library/random.html
> * [ ] DOC: upgrade cryptography docs in re: random numbers
>   * https://cryptography.io/en/latest/random-numbers/
> * [ ] ENH: random_(algo=) (~IRandomSource)
> * [ ] ENH: Add arc4random
> * [ ] ENH: Add chacha
> * [ ] ENH: Add OpenBSD's
> * [ ] BUG,SEC: new secure default named random.random
>   * must also be stateful / **reproducible** (must support .seed)
>   * justified as BUG,SEC because: [secure by default is the answer]
>     * https://en.wikipedia.org/wiki/Session_fixation
>       * https://cwe.mitre.org/data/definitions/384.html
>         * The docs did not say "you should know better."
>       * see also: hash collisions: https://bugs.python.org/issue13703
>   * [ ] REF: random.random -> random.random_old
>> M.-A. Lemburg writes:
>>  > I'm pretty sure people doing crypto will know and most others
>>  > simply don't care :-)
>> Which is why botnets have millions of nodes.  People who do web
>> security evidently believe that inappropriate RNGs have something to
>> do with widespread security issues.  (That doesn't mean they're right,
>> but it gives me pause for thought -- evidently, Guido thought so too!)
>>  > Evidence: We used a Wichmann-Hill PRNG as default in random
>>  > for a decade and people still got their work done.
>> The question is not whether people get their work done.  People work
>> (unless they're seriously dysfunctional), that's what people do.
>> Especially programmers (cf. GNU Manifesto).  The question is whether
>> the work of the *crackers* is made significantly easier by security
>> holes that are opened by inappropriate use of random.random.
>> I tend to agree with Steven d'A. (and others) that the answer is no:
>> it doesn't matter if the kind of person who leaves a key under the
>> third flowerpot from the left also habitually leaves the door unlocked
>> (especially if "I'm only gonna be gone for 5 minutes"), and I think
>> that's likely.  IOW, installing crypto strong RNGs as default is *not*
>> analogous to the changes to SSL support that were so important that
>> they were backported to 2.7 in a late patch release.
>> OTOH, why default to crypto weak if crypto strong is easily available?
>> You might save a few million Debian users from having to regenerate
>> all their SSH keys.[1]
>> But the people who are "just getting work done" in new programs *won't
>> notice*.  I don't think that they care what's under the hood of
>> random.random, as long as (1) the API stays the same, and (2) the
>> documentation clearly indicates where to find PRNGs that support
>> determinism, jumpahead, replicability, and all those other good
>> things, for the needs they doesn't have now but know they probably
>> will have some day.  The rub is, as usual, existing applications that
>> would have to be changed for no reason that is relevant to them.
>> Note that arc4random is much simpler to use than random.random.  No
>> knobs to tweak or seeds to store for future reference.  Seems
>> perfectly suited to "just getting work" done to me.  OTOH, if you have
>> an application where you need replicability, jumpahead, etc, you're
>> going to need to read the docs enough to find the APIs for seeding and
>> so on.  At design time, I don't see why it would hurt to select an
>> RNG algorithm explicitly as well.
>>  > Why not add ssl.random() et al. (as interface to the OpenSSL
>>  > rand APIs) ?
>> I like that naming proposal.  I'm sure changing the nature of
>> random.random would annoy the heck out of *many* users.
>> An alternative would be to add random.crypto.
>>  > Some background on why I think deterministic RNGs are more
>>  > useful to have as default than non-deterministic ones:
>>  >
>>  > A common use case for me is to write test data generators
>>  > for large database systems. For such generators, I don't keep
>>  > the many GBs data around, but instead make the generator take a
>>  > few parameters which then seed the RNGs, the time module and
>>  > a few other modules via monkey-patching.
>> If you've gone to that much effort, you evidently have read the docs
>> and it wouldn't have been a huge amount of trouble to use a
>> non-default module with a specified PRNG -- if you were doing it now.
>> But you have every right to be very peeved if you have a bunch of old
>> test runs you want to replicate with a new version of Python, and
>> we've changed the random.random RNG on you.
>> Footnotes:
>> [1]  I hasten to add that a programmer who isn't as smart as he thinks
>> he is who "improves" a crypto algorithm is far more likely than that
>> the implementer of a crypto suite would choose an RNG that is
>> inappropriate by design.  Still, it's a theoretical possibility, and
>> security is about eliminating every theoretical possibility you can
>> think of.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150911/77c69283/attachment-0001.html>

More information about the Python-ideas mailing list