Re: rnd entropy estimate running low?

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

It generated some bits at boot time, but apparently not early
enough, because on each reboot the kernel log looks like this:

...
total memory = 1024 MB
avail memory = 1007 MB
sysctl_createv: sysctl_create(machine_arch) returned 17
rnd: callout attached as an entropy source (collecting)
rnd: initialised (4096) with counter
rnd: printf attached as an entropy source (collecting without estimation)
rnd: autoconf attached as an entropy source (collecting)
rnd: WARNING! initial entropy low (5).
rnd: starting statistical RNG test, entropy = 6.
rnd: statistical RNG test done, entropy = 6.
rnd: entropy estimate 0 bits
rnd: asking source callout for 512 bytes
rnd: WARNING! initial entropy low (0).
rnd: entropy estimate 0 bits
rnd: asking source callout for 512 bytes
rnd: system-power attached as an entropy source (collecting)
mainbus0 (root)
cpu0 at mainbus0 core 0: 1536 MHz Cortex-A5 r0p1 (Cortex V7A core)
...

I'm assuming this is because this happens too early, the rng
device hasn't been detected so early in the boot process, and
there's no file system accessible either to re-initialize the
kernel rng from either at this stage, and the boot loader doesn't
have a way to work around this.

(This is more a platform-specific problem, I think, and
tangential to what I discussed initially.)

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

OK, I'll buy the crypto argument at face value.  However, our
code still behaves differently depending on whether the entropy
estimate is able to "satisfy" the request being processed or not.
So under this description that is also a holdover from older
versions of this code?

It may be coincidental, but this box when it sits otherwise
mostly idle and only does ntp for a long while sometimes logs

Kernel RNG "231 0 1" monobit test FAILURE: 10300 ones
cprng 231 0 1: failed statistical RNG test
...
Kernel RNG "15965 0 4" runs test FAILURE: too many runs of 4 1s (386 >= 384)
cprng 15965 0 4: failed statistical RNG test
...
Kernel RNG "27778 0 3" poker test failure: parameter X = 2.9280
cprng 27778 0 3: failed statistical RNG test
...
Kernel RNG "6647 0 3" poker test failure: parameter X = 47.2720
cprng 6647 0 3: failed statistical RNG test
...
Kernel RNG "24153 0 3" long run test FAILURE: Run of 29 0s found
cprng 24153 0 3: failed statistical RNG test
...
Kernel RNG "2551 0 4" poker test failure: parameter X = 47.60320
cprng 2551 0 4: failed statistical RNG test
...

Admittedly, these are spread over a larger time period, and a
couple of them were the result of provocation by dumping data
from /dev/random with dd.

Regards,

- Håvard