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

[Dirk-Willem van Gulik]

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.
> 
> 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. Once the pools are primed you could trickle entropy in in
> smaller amounts if you wish.

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

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

Or should it be properly whitened first ?

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.

With kind regards,

Dw.

1: https://13-37.org/en/shop/infinite-noise-trng/
2: https://github.com/manuel-domke/infnoise