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

[Dirk-Willem van Gulik]

On 12 Jul 2018, at 19:32, Conrad Meyer <cem at freebsd.org> wrote:
> 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 :-).

Clear thanks ! And it is indeed that space I care about. As it is there where we see hang/wait for entropy and the very occasional identical result in CI testing.

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

Excellent - I have my marching orders. Much appreciated !

Is there any point - much later post boot, in a non-network, read-only situation with essentially just 3 or 4 user processes running with no IO or interaction - to send some entropy (withewashed (or raw with random_harvest_queue()) to wards the PRNG ?

Or is that pointless from thereon.

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

As we’ve found out the hard way (although we are not sure it is indefinitely).

> 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.
 
Thanks for that. Unfortunately we’re in a read-only situation. And we’ve had CI testing yield identical results a few times now.

Dw.