New submission from STINNER Victor: 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". https://lwn.net/Articles/659643/ ---------- messages: 267646 nosy: haypo priority: normal severity: normal status: open title: Add os.urandom_block() versions: Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27250> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
