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 lemburg
Recipients Colm Buckley, Lukasa, alex, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.13:01:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5756C5B3.8090009@egenix.com>
In-reply-to <1465303232.29.0.991986972079.issue26839@psf.upfronthosting.co.za>
Content
On 07.06.2016 14:40, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
> (Basically) nobody should ever use /dev/random (and cryptographers agree!). The thing you want to use is /dev/urandom and the fact that /dev/urandom on Linux doesn't block before the pool is initalized has long been considered by cryptographers to be a fairly large flaw. The ``getrandom()`` calls were added explicitly to allow programs to get the correct behavior out of the system random.

Sounds to me that what you really want is os.getrandom() and not
a change in the implementation of os.urandom().

I think that would be a better solution overall: we get os.getrandom()
with access to all options and have os.urandom be the non-blocking
interface to /dev/urandom it has always been.

> For more information see http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ or http://www.2uo.de/myths-about-urandom/. The /dev/urandom man page is wrong, and it's wrong for political reasons and because Ted T'so has bad opinions.

I'm not sure what you are trying to tell me with those blog
posts or comments. The concept of trying to measure entropy
in an entropy pool is certainly something that people can have
different opinions about, but it's not wrong per-se when you
don't have easy access to a hardware device providing truely
random data (as in the Raspi SoC).

IMO, blocking is never a good strategy, since it doesn't increase
security - in fact, it lowers it because it opens up a denial
of service attack vector. Raising an exception is or providing other
ways of letting the application decide.
History
Date User Action Args
2016-06-07 13:01:45lemburgsetrecipients: + lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 13:01:44lemburglinkissue26839 messages
2016-06-07 13:01:44lemburgcreate