Re: rnd entropy estimate running low?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Thu, 12 Jan 2017 21:13:03 +0100 (CET)
> From: Havard Eidnes <he%NetBSD.org@localhost>
>
> Meanwhile the hardware random generator sits there unused.

Does it sit there completely unused, or did it get used a little at
boot time?  That's the most important time to use it; otherwise it
doesn't really matter, unless you somehow know an attacker has
witnessed the state of the kernel entropy pool, but otherwise expect
the system to be uncompromised.

> I would have thought it would make more sense to keep the "bits
> currently stored in pool" more "topped up", and that a re-fill
> could with benefit be done before the estimate crept down towards
> zero?  Especially if you have a half-way decent hardware random
> generator at hand?

Actually, no.  One basic conceit of modern symmetric cryptography is
that from a single small uniform random 256-bit secret, you can derive
an arbitrarily large uniform random secret.  `Entropy depletion' does
not really exist as a meaningful concept in modern cryptography.

The entropy accounting that we currently do is a holdover from days of
yore when the folklore supported it, but the natural information-
theoretic interpretation of the folklore actually leads to worse
attacks in practice -- see the rnd(4) man page for details.  So while
we haven't gotten rid of the kooky accounting, it doesn't really mean
anything to see the numbers go down.

There is a limit to the output produced by, e.g., AES-CTR, arising
from the PRP approximation to a PRF and the birthday paradox, and
there are some US federal government standards (NIST SP800-90A, in
particular) about PRNG constructions that Thor wanted to make it easy
to follow, which is why we rekey cprng(9) after a relatively small
amount of output -- but that happens much slower than the entropy
accounting you're looking at, and is not reported to userland.