Marc-Andre Lemburg added the comment: 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 implementation. 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. """ https://docs.python.org/3.5/library/os.html?highlight=urandom#os.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. http://fios.sector16.net/hardware-rng-on-raspberry-pi/, not on /dev/random or /dev/urandom: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
