Re: getrandom and getentropy

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

Joerg Sonnenberger wrote:
> > There's nothing wrong with the general idea of entropy estimation as
> > implemented in NetBSD-current.  If you run -current on your hypothetical
> > emulator, it will calculate an entropy estimate of zero, and
> > /dev/random will block, as it should.  The question we are trying to
> > decide in this thread is whether getentropy() (and consequently, based
> > on nia's list, things like openssl) should also block when this
> > happens, and I'm saying they should.
> 
> How should it known that it is not running on real physical hardware
> with random timing vs a deterministic environment with a programmable
> timing pattern? Hint: it can't.

Of course it can't, and I never said it could.  Since -current assigns
an entropy estimate of zero to all timestamp sources, any system that
doesn't have an entropy seed nor a hardware RNG (real or emulated)
will have a total entropy estimate of zero, whether it's running on
real hardware or in an emulator.

> Estimating entropy correctly is hard
> even from an external perspective of the system. It can be done somewhat
> reasonable if there is no whitening step involved and the actual
> physical process can be modelled (e.g. for microphone noise or a lava
> lamp), but it is still dangerous. See the mess of the Intel ICH random
> number generator where the floating diode accidentially got connected
> during the die shrink. So yes, the idea that the kernel can do more
> than completely guessing entropy for processes that designed to provide
> entropy is extremely questionable

I'm having trouble parsing the "processes that designed" part, but
otherwise I mostly agree.

> and therefore the idea that it makes sense to block in random places
> is the same.

The "random places" pun aside, since -current doesn't actually do
anything particularly questionable, I don't see how that follows.

> The operator is
> responsible for providing enough entropy during the boot process" is not
> really different from what we did before, just without all the voodoo.

The question is what should happen when the operator fails to do that.
Not that most computers even have "operators" nowadays.

> Few programs need to be aware of it at all.

Based on nia's list, some programs that do need to be aware are using
getentropy().  Both Linux and FreeBSD block in getentropy() when the
system thinks it lacks entropy, and I think NetBSD ought to behave
equally responsibly.  OpenBSD always thinks it has entropy, so it
makes no difference whether it specifies blocking behavior for
getentropy() or not.
-- 
Andreas Gustafsson, gson%gson.org@localhost