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

Tim Peters tim.peters at gmail.com
Mon Sep 14 05:34:58 CEST 2015


[Robert Kern <robert.kern at gmail.com>]
>> ...
>> I'll also recommend the PCG paper (and algorithm) as the author's
>> cross-PRNGs comparisons have been bandied about in this thread already. The
>> paper lays out a lot of the relevant issues and balances the various
>> qualities that are important: statistical quality, speed, and security (of
>> various flavors).
>>
>>   http://www.pcg-random.org/paper.html
>>
>> I'm actually not that impressed with Random123. The core idea is nice and
>> clean, but the implementation is hideously complex.

[Nathaniel Smith <njs at pobox.com>]
> I'm curious what you mean by this? In terms of the code, or...?
>
> I haven't looked at the code, but the simplest generator they
> recommend in the paper is literally just
>
> def rng_stream(seed):
>     counter = 0
>     while True:
>         # AES128 takes a 128 bit key and 128 bits of data and returns
> 128 bits of encrypted data
>         val = AES128(key=seed, data=counter)
>         yield low_64_bits(val)
>         yield high_64_bits(val)
>         counter += 1

I assume it's because if you expand what's required to _implement_
AES128() in C, it does indeed look pretty hideously complex.  On HW
implementing AES primitives, of course the code can be much simpler.

But to be fair, if integer multiplication and/or addition weren't
implemented in HW, and we had to write to C code emulating them via
bit-level fiddling, the code for any of the PCG algorithms would look
hideously complex too.

But being fair isn't much fun ;-)


More information about the Python-ideas mailing list