> Date: Thu, 12 Jan 2017 21:13:03 +0100 (CET) > From: Havard Eidnes <[email protected]> > > 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.
