Re: getrandom and getentropy

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

Taylor R Campbell wrote:
> > The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> > returns "high-quality" entropy, and do not caution against using it
> > for security critical purposes such as key generation, so presumably
> > applications do in fact use if for such purposes.  Given that,
> > implementing it as getrandom(..., GRND_INSECURE) seems like a bad
> > idea.
> 
> The term `high-quality' is, as they say, bearing a lot of load there.
> My message was meant to compare exactly what it means across several
> systems that have adopted the name `getentropy'.  It turns out that:
> 
> - On FreeBSD, it means 64 bytes of data (not data from a source with
>   512 bits of entropy total -- just 64 bytes of data) have been fed
>   into the pool.
> 
> - On Linux, it means that maybe some interrupts have come in at
>   irregular times within a single boot -- whatever is enough to fool
>   the `delta estimator', even if the times are exactly the same from
>   boot to boot and there is no physical justification for believing
>   them to be unpredictable.

Are these the same criteria as those used for unblocking /dev/random?

> In other words, it doesn't mean very much!

It means these systems block until they consider there to be
sufficient entropy.  NetBSD should do the same, only using better
criteria for what is considered sufficient entropy.

> On NetBSD-current we do not count either of these metrics.  Instead,
> what NetBSD-current does is:
> 
> 1. Makes best effort to get as many samples as it can into the entropy
>    pool early on -- like OpenBSD, which introduced the getentropy API
>    in the first place under that premise.

OpenBSD guarantees that there is an entropy seed from the boot loader,
which is very different from NetBSD's "best effort".  Was this not
already the case when the getentropy API was introduced?

> 2. Counts bits of entropy that have some justification:
>    . HWRNG drivers can make claims to the kernel based on the
>      documentation of how the physical device works or advertisements
>      made by the manufacturer (which the operator can disable with
>      rndctl -E if they know better than the driver author).
>    . The operator can make claims to the kernel by writing data to
>      /dev/random explicitly, so, e.g., you can flip a coin 256 times
>      and and write the outcomes to /dev/random.
>    . The kernel will believe one seed file entropy estimate per boot,
>      subject to various criteria (read/write medium, &c.) so it can
>      keep up the 256 coin flips from boot to boot.
> 
> The standard advice for many years has been that applications should
> read key material from /dev/urandom, and systems should be engineered
> to make sure that it's ready by the time applications run.

Which is unfortunate, because with the possible exception of OpenBSD,
systems haven't actually been engineered in such a way.

> The semantics of getrandom(..., GRND_INSECURE) is the same as the
> semantics of reading from /dev/urandom on Linux and in the patch I
> proposed, and I think that semantics is more or less what developers
> generally expect with the name getentropy.

It is certainly not what I would expect based on the getentropy() man
pages.

> On the other hand, (2) is a more stringent criterion than either
> FreeBSD or Linux applies -- for example, where Linux might believe
> there is some entropy in the timing of `keyboard' input provided by
> anita, NetBSD-current does not.
> 
> > Also, two of the man pages explicitly mention blocking, so any
> > portable software using getentropy() should already deal with it.
> > So why not do the safe thing and implement it as getrandom(..., 0)
> > == read from /dev/random?
> 
> That issue is why I'm not really happy about the getentropy API: it
> was originally defined to never block, and some systems have made it
> block for reasons that don't really mean very much.

Where is this original definition?  I checked the CVS history of the
OpenBSD getentropy(2) man page, and none of the versions mention
blocking at all, which is not the same thing as guaranteeing it will
never block.
-- 
Andreas Gustafsson, gson%gson.org@localhost