Charles-François Natali added the comment: > The default seeding for the random module currently used 32 bytes from > urandom() to create the initial state of the random number generator. > This is far less than the number of possible states 2**19937-1.
I'm not a cryptography expert, but IMO 32 bytes is more than enough: for example, ssh-keygen only reads 32 bytes from /dev/urandom when generating a new key (and I assume the authors know what they're doing). So I'm not sure that "convering the state space" is a good enough reason to increase the amount of data read: it can hut performance, not only for the singla process case, but also because /dev/urandom is protected by a spinlock/mutex, it can hurt workloads where multiple processes are simultaneously reading from /dev/urandom (which is the reason we switched to a persistent /dev/urandom FD), see e.g. http://drsnyder.us/2014/04/16/linux-dev-urandom-and-concurrency.html And I especially like this answer by Ted Ts'o (once again, I assume he knows what he's talking about): """ Doctor, doctor it hurts when I do this. Well, then don't do that! The reason for the spinlock is to avoid having two reads from /dev/urandom return the same results. That would be undesirable... If people are trying to read from /dev/urandom a huge number of times per second, then they're doing something wrong. The real issue, as Sebastian has pointed out, is that issue spawning a huge number of curl processes for each request. Then hopefully curl is using /dev/urandom to initialize its own userspace RNG (many crypto libraries do this; most *should* do this), so you're not trying to read from /dev/urandom for every single request. /dev/urandom is designed for security, not for speed. """ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21470> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com