Re: getrandom and getentropy

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, May 14, 2020 at 10:35:48AM +0300, Andreas Gustafsson wrote:
> 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.

But you are arguing that it should be able to do that all the time. Make
up your mind please. The root problem is not that the kernel uses zero
as entropy estimate for most entropy sources, but but there is no way to
assign one without knowing the physical processes or at least the
interface contracts of the hardware. I.e. a virtualized RNG is still a
virtualized RNG and if it works, it will provide the promised entropy.
That's about the only category of hardware that has this property
though. Now what do we have, all non-dedicated devices have no
guaranted entropy, but we can be reasonable sure that there is some in a
normal environment. Until when should be block?

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

A regular system installation using sysinst on most platforms will
create a seed file and the default installation will continue using that
to provide a base line with mixed in timing data from regular operation.
That's as good as you can normally do. It can fail if the system
operator leaks the seed file and not enough entropy is added until an
attacker can interact with the system. The primary mechanism for that is
operational (mis)handling, i.e. cloning a disk while preserving the seed
file. That is something that needs to be documented as it is a
procedural issue. Scripts that setup VM images need to be aware of it
and should remove the seed file or at least provide a mechanism for
having per-instance initial seeding.

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

I'd strongly argue that the only category where it really matters
potentially are long term key generators. I would at the same time
consider creating the ssh host keys as part of sysinst, but that's
already setting up the seed file handling too.

Joerg