> On Aug 7, 2016, at 2:33 PM, Ethan Furman <et...@stoneleaf.us> wrote: > > So if we work around the problem in SipHash, the issue goes away?
The issue goes away in the sense that starting the Python interpreter *at all* no longer relies on urandom being initialized. If someone uses Python early enough and calls os.urandom (directly or indirectly) then the same problem would occur again for that program. Working around the problem in SipHash simply moves the problem from anytime you try to use the Python interpreter early in the boot process, to anytime you ask for secure random from os.urandom early in the boot process. > And does that work-around mean SipHash may not be robust for that instance of > Python, but any Python process running that early should be short-lived > anyway, so any security issues become vanishingly rare? This is correct. The security properties of SipHash basically only matter for something that accepts a lot of untrusted input *and* lives a long time. This basically ends up only pretty much only applying to some sort of network available daemon (not entirely, but it’s the main case). It’s also true that the quality of random from urandom doesn’t go from something entirely predictable to entirely random at the exact moment the pool is fully initialized. The quality of random numbers get better the closer to pool initialization you are. This isn’t good enough for many use cases, but for SipHash it’s likely going to get reasonably OK random even in these early boot cases for that particular use case. As a hypothetical, if we wanted to push the needle even further we could *not* work around the SipHash problem and push that need to work around it onto folks calling Python that early by setting a static PYTHONHASHSEED, but the cost is not likely worth the reward. — Donald Stufft _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
