[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
devguide/documenting.html#security-considerations-and-other-concerns
https://docs.python.org/devguide/documenting.html#security-considerations-and-other-concerns
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