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

[Andreas Gustafsson <gson%gson.org@localhost>]

Taylor R Campbell wrote:
> > 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.)

Even if the unblocking criteria of Linux and FreeBSD are questionable,
they still provide more security than your proposal which amounts to
having extremely strict criteria but then completely ignoring.

> 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.

Which is why we should deal with the issue by creating an entropy seed
at the time of installation or first boot.

> 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.

To start with, we should re-enable the code Martin already added to
sysinst to prompt the user for missing entropy at install time, and we
should continue to work on making it easier to use.  For images and
other cases where sysinst isn't used, we also need a similar prompt at
the time of first boot.  We should also provide more entropy sources
with conservative but nonzero estimates to make those prompts
increasingly rare.

I don't think deliberately generating predictable keys and relying on
the operator to regenerate them later is a good idea (to put it
mildly).

> 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.

I'm not saying we should make Python programs hang, I'm saying we
should stop them from hanging by providing entropy rather than by
ignoring the lack of it.
-- 
Andreas Gustafsson, gson%gson.org@localhost