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.12:18:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 07.06.2016 13:51, Donald Stufft wrote:
> Donald Stufft added the comment:
>> That's pretty much in line with what the implementation now does.
> Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as long as your OS isn't broken, this will provide cryptographically safe random numbers. As Cory pointed out, random.SystemRandom and the new secrets module are both relying on this promise of cryptographically safe numbers to provide their functionality, as is a number of other, external Python programs.

Ah, that's what you call taking quotes out of context :-) The full
documentation reads:

Return a string of n random bytes suitable for cryptographic use.

This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable enough for
cryptographic applications, though its exact quality depends on the OS

On Linux, getrandom() syscall is used if available and the urandom
entropy pool is initialized (getrandom() does not block). On a Unix-like
system this will query /dev/urandom.

Note how the documentation emphasizes on os.urandom() not blocking.

I like the idea that Victor brought to allow applications to
check whether os.urandom() reverted to non-blocking /dev/urandom
or not. That way applications can make the right choices, while
still assuring that Python doesn't block on startup just to
init hash randomization (which has it's own set of issues).

BTW: /dev/urandom doesn't make many promises as to the quality
of the data on Linux. For crypto applications relying on real
entropy, it's better to gather data from a hardware source
with known properties, e.g., not on
/dev/random or /dev/urandom:
Date User Action Args
2016-06-07 12:18:18lemburgsetrecipients: + lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 12:18:18lemburglinkissue26839 messages
2016-06-07 12:18:18lemburgcreate