Re: Should our default random number generator be secure?

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?"
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-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/