This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.14:09:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465308584.55.0.665850864367.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
I'm with Donald here. Python must not reduce security just for a special case. It doesn't mean that we should not address and fix this special case -- just treat it as special.

1) For your use case, the hash randomization key for the SipHash PRN doesn't need to be 4 or 8 bytes of CPRNG. Since you are not dealing with lots of untrusted input from a malicious remote source, any unpredictable or even predictable value will do.

2) Your use case might be special enough to use a special build of Python. Too bad https://www.python.org/dev/peps/pep-0432/ is not ready yet. 

3) #21470 causes 'import random' to read os.urandom(2500) in order to initialize the MT state of random.random. I really don't understand why MT needs 2500 bytes of distinct CPRNG data. The module should rather read less data and then stretch it into a larger init vector. We could use SipHash for the job. In fact why does the MT use a CPRNG at all? It's not designed as CPRNG source and could be initialized from other sources (id(self), time()...) instead.
History
Date User Action Args
2016-06-07 14:09:44christian.heimessetrecipients: + christian.heimes, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 14:09:44christian.heimessetmessageid: <1465308584.55.0.665850864367.issue26839@psf.upfronthosting.co.za>
2016-06-07 14:09:44christian.heimeslinkissue26839 messages
2016-06-07 14:09:44christian.heimescreate