Re: Waiting for Randot (or: nia and maya were right and I was wrong)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 15 Jan 2021 20:54:21 +0200
> From: Andreas Gustafsson <gson%gson.org@localhost>
> 
>                                          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.