[Python-ideas] Should our default random number generator be secure?
mal at egenix.com
Thu Sep 10 18:38:49 CEST 2015
On 10.09.2015 17:46, Brett Cannon wrote:
> On Thu, 10 Sep 2015 at 01:26 M.-A. Lemburg <mal at egenix.com> wrote:
>> Reading this thread is fun, but it doesn't seem to be getting
>> anywhere - perhaps that's part of the fun ;-)
>> Realistically, I see two options:
>> 1. Someone goes and implements the OpenBSD random function in C
>> and put a package up on PyPI, updating it whenever OpenBSD
>> thinks that a new algorithm is needed or a security issue
>> has to be fixed (from my experience with other crypto software
>> like OpenSSL, this should be on the order of every 2-6 months ;-))
>> 2. Ditto, but we put the module in the stdlib and then run around
>> issuing patch level security releases every 2-6 months.
> I see a third: rename random.random() to be be something that gets the
> point across it is not crypto secure and then stop at that.
I think this is the major misunderstanding here:
The random module never suggested that it generates pseudo-random data
of crypto quality.
I'm pretty sure people doing crypto will know and most others
simply don't care :-)
Evidence: We used a Wichmann-Hill PRNG as default in random
for a decade and people still got their work done. Mersenne
was added in Python 2.3 and bumped the period from
6,953,607,871,644 (13 digits) to 2**19937-1 (6002 digits).
> I don't think
> the stdlib should get into the game of trying to provide a RNG that we
> claim is cryptographically secure as that will change suddenly when a
> weakness is discovered (this is one of the key reasons we chose not to
> consider adding requests to the stdlib, for instance).
> Theo's key issue is misuse of random.random(), not the lack of a
> crypto-appropriate RNG in the stdlib (that just happens to be his solution
> because he has an RNG that he is partially in charge of). So that means
> either we take a "consenting adults" approach and say we can't prevent
> people from using code without reading the docs or we try to rename the
> function. But then again that won't help with all of the other functions in
> the random module that implicitly use random.random() (if that even
> matters; not sure if the helper functions in the module have any crypto use
> that would lead to their misuse).
> Oh, and there is always the nuclear 4th option and we just deprecate the
> random module. ;)
Why not add ssl.random() et al. (as interface to the OpenSSL
rand APIs) ?
By putting the crypto random stuff into the ssl module, even
people who don't know about the difference, will recognize
that the ssl version must be doing something more related to
crypto than the regular random module one, which never promised
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.
This allows me to create reproducible test sets in a very
efficient way. The feature to be able to reproduce a set is
typically only needed when tracking down a bug in the
system, but the whole setup avoids having to keep the whole
test sets around on disk.
Professional Python Services directly from the Source (#1, Sep 10 2015)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2015-09-18: PyCon UK 2015 ... 8 days to go
::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Python-ideas