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

Tim Peters tim.peters at gmail.com
Thu Sep 10 06:47:53 CEST 2015


[Tim, on parallel PRNGs]
>> There are some clean and easy approaches to this based on
>> crypto-inspired schemes, but giving up crypto strength for speed.  If
>> you haven't read it, this paper is delightful:
>>
>>     http://www.thesalmons.org/john/random123/papers/random123sc11.pdf

[Nathaniel Smith]
> It really is! As AES acceleration instructions become more common
> (they're now standard IIUC on x86, x86-64, and even recent ARM?), even
> just using AES in CTR mode becomes pretty compelling -- it's fast,
> deterministic, provably equidistributed, *and* cryptographically
> secure enough for many purposes.

Excellent - we're going to have a hard time finding something real to
disagree about :-)


> (Compared to a true state-of-the-art CPRNG the naive version fails due
> to lack of incremental mixing, and the use of a reversible transition
> function. But even these are mostly only important to protect against
> attackers who have access to your memory -- which is not trivial as
> heartbleed shows, but still, it's *waaay* ahead of something like MT
> on basically every important axis.)

Except for wide adoption.  Most people I bump into never even heard of
this kind of approach.  Nobody ever got fired for buying IBM, and
nobody ever got fired for recommending MT - it's darned near a
checklist item when shopping for a language.  I may have to sneak the
code in while you distract Guido with a provocative rant about the
inherent perfidy of the Dutch character ;-)


More information about the Python-ideas mailing list