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

[Stephen J. Turnbull]

Tim Peters writes:
 > [M.-A. Lemburg]
 > >> I'm pretty sure people doing crypto will know and most others
 > >> simply don't care :-)
 > 
 > [Stephen J. Turnbull <stephen at xemacs.org>]
 > > Which is why botnets have millions of nodes.
 > 
 > I'm not a security wonk, but I'll bet a life's salary ;-) we'd have
 > botnets just as pervasive if every non-crypto RNG in the world were
 > banned - or had never existed.

I am in violent agreement with you on that point and most others.[1]
However, the analogy was not intended to be so direct as to imply that
"insecure" RNGs are responsible for botnets, merely that not caring
is.  I agree I twisted MAL's words a bit -- he meant most people have
no technical need for crypto, and so don't care, I suppose.  But then,
"doing crypto" (== security) is like "speaking prose": a lot of folks
doing it don't realize that's what they're doing -- and they don't
care, either.

 > So long as end users are allowed to run programs, that problem will
 > never go away.

s/users/programmers/ and s/run/write/, and we get a different analogy
that is literally correct -- but fails in an important dimension.  One
user's mistake adds one node to the botnet, and that's about as bad as
one user's mistake gets in terms of harm to third parties.  But one
programmer's (or system administrator's) mistake can put many, perhaps
millions, at risk.

Personally I doubt that justifies an API break here, even if we can
come up with attacks where breaking the PRNG would be cost-effective
compared to "social engineering" or theft of physical media.  I think
it does justify putting quite a bit of thought into ways to make it
easier for naive programmers to do the "safe" thing even if they
technically don't need it.

I will say that IMO the now-traditional API was a very unfortunate
choice.  If you have a CSPRNG that just generates "uniform random
numbers" and has no user-visible APIs for getting or setting state,
it's immediately obvious to the people who know they need access to
state what they need to do -- change "RNG" implementation.  The most
it might cost them is rerunning an expensive base case simulation with
a more appropriate implementation that provides the needed APIs.

On the other hand, if you have something like the MT that "shouldn't
be allowed anywhere near a password", it's easy to ignore the state
access APIs, and call it the same way that you would call a CSPRNG.
In fact that's what's documented as correct usage, as Paul Moore
points out.  Thus, programmers who are using a PRNG whose parameters
can be inferred from its output, and should not be doing so, generally
won't know it until the (potentially widespread) harm is done.  It
would be nice if it wasn't so easy for them to use the MT.


Footnotes: 
[1]  I think "agree with Tim" is a pretty safe default.<wink/>