<div dir="ltr">On Fri, Jan 17, 2020 at 10:08 AM bsr wrote:<br><div>> I am wondering if there have been any new developments pertaining to this matter. Correct me if I am wrong, but if I understand correctly, the changes being implemented(?) will significantly (dare I write 'negatively') affect how external HWRNG devices such as OneRNG contribute to the kernel entropy pool.</div><div><br></div><div>I'm not sure, but I think what's happening is that the entropy *estimates* are being used only for startup, and no longer consulted during the normal lifetime of use.</div><div>/dev/random has been behaving in the same way as /dev/urandom for a long time (i.e. they're both just PRNGs, that reseed periodically) with the exception that /dev/random was going to block if you had read "too much" from it compared to the rate of entropy input as estimated.</div><div><br></div><div>To go with this, it seems like Ted is now making explicit that /dev/random is not crypto-suitable. "So if it's just for cryptographers, then let it all be done in
userspace". Seems to be a feeling that 'generating session keys' is not crypto?<br></div><div><br></div><div>All the existing software mechanisms (like, writing to /dev/random) will continue to work, because they really dislike removing API features :-)</div><div><br></div><div>> To me after reading all the discussion, it seems nearly certain that the blocking pool will essentially be eliminated. Am I correct that other than the guarantee that /dev/random will block until seeding the CRNG/DRNG (ChaCha20) with 256 bits of "true" entropy, it will behave like /dev/urandom? So now we must trust the DRNG and its implementation, right? If those bits leak (state extension attack) isn't everything pwnd?</div><div><br></div><div>Yes, but I think this has been the case for a long time anyway.</div><div><br></div>> I understand the problems that arose from blocking behavior under certain circumstances and the need for a solution, but this is a monumental shift from my perspective. Depending on what comes to pass, I guess one can always build a custom kernel but that would probably be a maintinence nightmare. I realize my tin foil hat is thicker than most so maybe I sound unreasonable.<br><div><br></div><div>Finding sources of entropy across all the different places that Linux can run is incredibly difficult; this change feels more like the kernel team have given up completely. I suspect this will cause some future problems where embedded and virtual machines will have no entropy gathering but will still have to do crypto, but the developers are not going to notice ...</div><div><br></div><div>*But* the disclaimer on all this is that I've never been a Linux kernel developer of any kind, and nothing changes the whole point of OneRNG - an entropy source that you can inspect, verify, hack on and therefore start to trust :-) We're not here to "fix Linux", Theo deRaadt told me that OpenBSD doesn't need us (although it can't hurt, lol), and Windows is still a mystery. <br></div><div><br></div><div>-jim<br></div></div>