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 vstinner
Recipients vstinner
Date 2016-06-07.12:21:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The change of the issue #26839 creates a long discussion around the behaviour of os.urandom() when the entropy pool is not seeded with enough entropy.

On Python 2.7, os.urandom() doesn't block in this case. I expect that bytes are random, but not "random enough" to generate a cryptographic key.

I propose to add a new os.urandom_block() function which is similar to os.urandom(), but with one single difference: don't fallback on reading /dev/urandom on Linux with the entropy pool is not initialized yet.

In short, os.urandom() can be used for everything except generating cryptographic keys. os.urandom_block() is suitable for cryptographic keys.


I expect that security experts would prefer the opposite: add a new os.pseudo_random() function and make os.urandom() blocking by default.

Let me elaborate my rationale. Python is used in various areas. In most cases, random is not used for security purpose, but for game, simulation, numerical computation, etc. "random" term is large in Python:

* random seed for the randomized hash function: Python SIPHASH requires 24 random bytes
* importing the random modules immediatly instanciate a random.Random which is Mersenne Twister RNG which requires not less than 2500 random bytes

These two users of random bytes blocked Python startup: see issue #26839.

I consider that random is used in more cases for game, simulation, etc. than for security.

That's why the secrets module was added to Python 3.6 rather than making the random module "more secure".
Date User Action Args
2016-06-07 12:21:07vstinnersetrecipients: + vstinner
2016-06-07 12:21:07vstinnersetmessageid: <>
2016-06-07 12:21:07vstinnerlinkissue27250 messages
2016-06-07 12:21:07vstinnercreate