On 2016-06-10 20:42, Chris Jerdonek wrote:
On Fri, Jun 10, 2016 at 11:29 AM, David Mertz <mertz@gnosis.cx> wrote:
This is fairly academic, since I do not anticipate needing to do this myself, but I have a specific question. I'll assume that Python 3.5.2 will go back to the 2.6-3.4 behavior in which os.urandom() never blocks on Linux. Moreover, I understand that the case where the insecure bits might be returned are limited to Python scripts that run on system initialization on Linux.
If I *were* someone who needed to write a Linux system initialization script using Python 3.5.2, what would the code look like. I think for this use case, requiring something with a little bit of "code smell" is fine, but I kinda hope it exists at all.
Good question. And going back to Larry's original e-mail, where he said--
On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings <larry@hastings.org> wrote:
THE PROBLEM ... The issue author had already identified the cause: CPython was blocking on getrandom() in order to initialize hash randomization. On this fresh virtual machine the entropy pool started out uninitialized. And since the only thing running on the machine was CPython, and since CPython was blocked on initialization, the entropy pool was initializing very, very slowly.
I repeat for like the fifth time: os.urandom() and Python startup are totally unrelated. They just happen to use the same internal function to set the hash randomization state. The startup problem can be solved without f... up the security properties of os.urandom(). The correct questions to ask are: 1) Does hash randomization for bytes, text and XML always require cryptographically strong random values from a potentially blocking CPRNG? 2) Does the initial state of the Mersenne-Twister of the default random.Random instance really need cryptographically strong values? 3) Should os.urandom() always use the best CSPRNG source available and make sure it never returns weak, predictable values (when possible)? The answers are: 1) No 2) No 3) HELL YES! If you think that the answer to 3 is "No" and that a CSPRNG is permitted to return predictable values, then you are *by definition* ineligible to vote on security issues. Christian