Message 267635 - Python tracker (original) (raw)

IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains that the property of blocking or not blocking doesn't matter for the quality of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we please stay focused on the uninitialized entropy pool case?

Cory wasn't speaking about (non)blocking in general, but the case where (apparently) it's desired to not block even if that means you don't get cryptographically secure random in the CPython interpreter start up. Nobody here wants os.urandom to behave like /dev/random does on Linux. We just want os.urandom to always return cryptographically safe random numbers.

IMHO you are expecting too much from os.urandom(). If you consider that secrets require an initialized entropy pool, IMHO you should help Stephan to implement a function to retrieve the implementation of os.urandom() and then take a decision in the secrets module. For example, raise an exception. It's the best way to warn users that something goes wrong. I don't think that blocking is a good choice.

I think this is a pretty crappy way of handling it-- blocking for a short amount of time is almost always going to be the right thing for people here, particularly since it only matters right at the start of a fresh VM and no other time. I think that it's wrong to let an edge case of PYTHONHASHSEED reduce the security and the ability to reason about the return value of os.urandom for basically every other application of it.