Limits to seeding /dev/random | random(4)

[Conrad Meyer]

On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik
<dirkx at webweaving.org> wrote:
> On 12 Jul 2018, at 17:57, RW via freebsd-hackers <freebsd-hackers at freebsd.org> wrote:
>> On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote:
>>
>>> When asking our prng gurus for advice on writing a device driver for
>>> an on-chip entropy source, the advice I got was basically: there's no
>>> need to feed in more entropy on an ongoing basis, but no harm in
>>> doing so either, within reason. The recommendation was to feed at or
>>> below an average rate of about 128 bits/second. Pushing in more isn't
>>> harmful, just wasteful of system resources because it doesn't make
>>> anything better.
>>
>> This is a bit simplistic because it ignores the way that fortuna
>> stripes entropy across 32 pools.

RW, you and Ian are talking about different things.  Ian is talking
about post-seed, additional entropy from a hardware device.  You are
talking about initial seeding.  You're both right, but talking past
each other :-).

>> In order to fully secure the prng at boot time you need to get 256 bits
>> of entropy into it, and to guarantee that you need to have 256 bits in
>> pool[0], which means you need to write 256*32=8192 bits into the random
>> device. This should be done as early in the rc.d boot process as
>> possible.

For example, it is done by the loader, as well as the /etc/rc.d/random
script using entropy saved from the RNG at shutdown on any FreeBSD
with a writable /, /var, or /boot.

>> Once the pools are primed you could trickle entropy in in
>> smaller amounts if you wish.

Right — that's what Ian is suggesting.

> So these HW devices [1] give us a raw feed — which one usually whitewashes [2] in order to use.

Don't feed the raw data — use the washed bits.

> It is fairly well defined how many bits of entropy we get ‘raw’.
>
> During boot - can I feed the right number of bits without whitewashing - letting the kernel do the trick (much like random_harvest_queue() does in for example the mouse driver) ?

Why feed less random data to the kernel when you have a relatively
high throughput random device available?  Your device generates 90
kbps after washing — it'll take at most 90 ms to fully seed
/dev/random at that rate, even with a readonly filesystem
embedded-type device.

> Or should it be properly whitened first ?

Yes :-).

> Our goal is to get to a point where a very stripped down BSD can be booted up (sans network or much in terms of attached devices but for a printer and chipcard reader) — yet is know to have a solid seeded RNG.

/dev/u?random never produces unseeded results.  If it is not seeded,
reads will just block indefinitely, until it is seeded.

To seed the device without a writable filesystem, write 1kB+ of
whitened random from your device into /dev/random early in boot, and
you will be good to go.  You can do the ongoing trickle after that if
you want, but it is not necessary.  On FreeBSD 12-CURRENT, you can
verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no
longer returns -1 with EAGAIN errno.  If you need to use a FreeBSD
prior to 12, you'll know random is seeded when reads no longer block.

All the best,
Conrad