> Date: Fri, 15 Jan 2021 20:54:21 +0200 > From: Andreas Gustafsson <g...@gson.org> > > Your proposal would mean that > such an application would generate predictable keys on NetBSD when no > entropy is available, even though it will not on Linux. To me, that's > completely unacceptable.
This is not accurate, because the criteria for unblocking are qualitatively different. Linux will unblock when the `entropy estimator' -- which is designed without knowledge of any of the physical details of the entropy sources, and roughly counts whether successive differences of successive differences of 32-bit samples are distinct -- has been fooled into counting enough bits. FreeBSD will unblock when a certain fixed number of bytes of samples have been entered, no matter what sources they came from. (I forget what the number is offhand but I seem to recall it's around 64 bytes.) More details and references from the prior discussion: https://mail-index.netbsd.org/tech-userlevel/2020/05/09/msg012390.html https://mail-index.netbsd.org/tech-userlevel/2020/05/10/msg012406.html In answer to a question you had which seems to have gone unanswered at the time: > Are these the same criteria as those used for unblocking /dev/random? Yes. And NetBSD, as you know, has a much more stringent criterion for unblocking anything. Over the past ~year of experience, we've seen the blocking behaviour of getrandom(p,n,0) lead to practical problems that are confusing and leave applications in a state that isn't conducive to remedying the problem -- as I said in the initial message (https://mail-index.netbsd.org/tech-userlevel/2021/01/11/msg012807.html): It's certainly a problem when keys are generated with too little entropy -- e.g., https://factorable.net -- but it's increasingly clear that _the middle of an application trying to get something else done_ is not a good place for hanging until someone plugs in a USB HWRNG. Such an application, like a Python program in the middle of just doing `import multiprocessing', is not in a position to remedy the situation or even usefully alert an operator to the problem. I'm open to improvements to the system integration. For example, aside from the security report and entropy=check/wait in rc.conf and a potential one-line notice in the motd, I'm also considering how to unobtrusively record a log of long-term keys that may have been generated without enough entropy (e.g., ssh-keygen in /etc/rc.d/sshd), so that an operator can conveniently review the log and regenerate them once entropy is available. But if we're to keep the blocking behaviour at the point where any application is generating a key, then I'd like to have a stronger justification for how making every other Python program just silently hang forever on some machines helps further any broader goal.
