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

M.-A. Lemburg mal at egenix.com
Tue Sep 15 10:45:34 CEST 2015

On 15.09.2015 09:36, Nathaniel Smith wrote:
> [Using empirical tests to check RNGs]
> Obviously the thing the scientists worry about is a *strict* subset of
> what the cryptographers are worried about. 

I think this explains why we cannot make ends meet:

A scientist wants to be able to *repeat* a simulation in exactly the
same way without having to store GBs of data (or send them to colleagues
to have them very the results).

Crypto RNGs cannot provide this feature per design.

What people designing PRNGs are after is to improve the statistical
properties of these PRNGs while still maintaining the repeatability
of the output.

> This is why it is silly to
> worry that a crypto RNG will cause problems for a scientific
> simulation. The cryptographers take the scientists' real goal -- the
> correctness of arbitrary programs like e.g. a monte carlo simulation
> -- *much* more seriously than the scientists themselves do. (This is
> because scientists need RNGs to do their real work, whereas for
> cryptographers RNGs are their real work.)

Yes, cryptographers are the better folks, understood. These arguments
are not really helpful. They are not even arguments.

It's really simple: If you don't care about being able to reproduce
your simulation results, you can use a crypto RNG, otherwise
you can't.

> Compared to this, k-dimensional equidistribution is a red herring: it
> requires that you have a RNG that repeats itself after a while, and
> within each repeat it produces a uniform distribution over bitstrings
> of some particular length.

k-dim equidistribution is a way to measure how well your
PRNG behaves, because it describes in analytical terms how
far you can get with increasing the linear complexity of your
RNG output. The goal is not to design an PRNG with specific
k, but to increase k as far as possible, given the RNGs
deterministic limitations.

It's also not something you require of a PRNG, it's simply
a form of analytical measurement, just like the tests in TestU01
or the NIST test set are statistical measurements for various
aspects of RNGs.

Those statistical tests are good in detecting flaws of certain kinds,
but they are not perfect. If you know the tests, you can work around
them and have your RNG appear to pass them, e.g. you can trick a
statistical test for linear dependencies by applying a non-linear
transform. That doesn't make the RNGs better, but it apparently is
a way to convince some people of the quality of your RNG.

> By contrast, a true random bitstring does
> not repeat itself, and it gives a uniform distribution over bitstrings
> of *arbitrary* length. In this regard, crypto RNGs are like true
> random bitstrings, not like k-equidistributed RNGs. This is a good
> thing. k-equidistribution doesn't really hurt (theoretically it
> introduces flaws, but for realistic designs they don't really matter),
> but if randomness is what you want then crypto RNGs are better.

If you can come up with a crypto RNG that allows repeating the
results, I think you'd have us all convinced, otherwise it
doesn't really make sense to compare apples and oranges,
and insisting that orange juice is better for you than
apple juice ;-)

Marc-Andre Lemburg

Professional Python Services directly from the Experts (#1, Sep 15 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
2015-09-14: Released mxODBC Plone/Zope DA 2.2.3   http://egenix.com/go84
2015-09-18: PyCon UK 2015 ...                               3 days to go
2015-09-26: Python Meeting Duesseldorf Sprint 2015         11 days to go

   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 mailing list