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.
> 
> But you are arguing that it should be able to do that all the time. 

I don't understand what you are referring to here.  What exactly do
you think I'm arguing?

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

Until the kernel thinks it has sufficient entropy, the way /dev/random
already works.

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

A regular system installation using sysinst should first check if the
installer itself has sufficient entropy, and if not, give the user the
opportunity to supply additional entropy.  It should then create a
seed file on the installed system containing an entropy estimate
corresponding to the installer's estimate.  The installed system
should trust the estimate in the seed.

If this all goes according to plan, the installed system will have an
entropy estimate exceeding its acceptance threshold thanks to the seed
alone, and no requests for randomness will block.  If things do not go
according to plan and the installed system has neither a seed with a
sufficiently large estimate nor a HWRNG, reads from /dev/random and
calls to getentropy() should both block.

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

This part I fully agree with.

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

Why do you think it does not matter for things like session keys?
-- 
Andreas Gustafsson, gson%gson.org@localhost