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

[Dirk-Willem van Gulik]

> On 11 Jul 2018, at 15:58, Ian Lepore <ian at freebsd.org> wrote:
> 
> On Wed, 2018-07-11 at 14:03 +0200, Dirk-Willem van Gulik wrote:
>> When feeding /dev/random from hardware USB devices like Bill
>> Woodcock’s design in PCB incarnation:
>> 
>> 	https://13-37.org/de/shop/infinite-noise-trng/
>> 
>> Are there any caveats with regard to volume or speed of doing so ? Or
>> is it always a plus ? 
>> 
>> Actual code at https://github.com/dirkx/infnoise/blob/master/software
>> /libinfnoise.c line 122:
>> 
>> 	if ((devRandomFD = open("/dev/random",O_WRONLY)) <0)
>> 		.. error handling
>> 
>> 	if (write(devRandomFD, bytes, length) != length) 
>> 		.. error handling
>> 
>> And is there any case where length would not return the length
>> written — it seems that the driver traps/ignores EINT, EAGAIN and
>> short writes ? 
>> 
>> Or should one check the entropy available in /dev/random (how?) and
>> hold off feeding it until it is low enough (this is what the
>> infinite-trng seems to do on linux).
>> 
>> With kind regards,
>> 
>> Dw
> 
> There is no way to check the entropy available in /dev/random because
> the whole concept doesn't apply. Entropy isn't a limited resource that
> can be exhausted after the prng is seeded at boot time.
> 
> 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.

Understood. But it is not a bad thing if one also takes into account all sort of governance stuff around certification & what not (and we got bitten at least twice by a virtualised environment producing something identical - which with hindsight was obvious but still).

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

Ok - so these units spit out around a 90-100 K bit/second (that is after it has been whitewashed by a Keccack-1600).

So I guess I should not pass all of that on blindly — but quell that stream by a factor thousand.

Dw.