> Date: Sun, 10 May 2020 14:24:00 +0300
> From: Andreas Gustafsson <g...@gson.org>
>
> 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.
In other words, it doesn't mean very much!
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.
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.
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.
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.
This is an argument for providing just getrandom -- the API contract
is is clearer and doesn't require long detailed messages summarizing
research into exactly what the blocking criteria are and what the
practical consequences for them are.
