Date: Wed, 11 Jul 2018 16:34:29 +0200 From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: Ian Lepore <ian@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Limits to seeding /dev/random | random(4) Message-ID: <DA8D22E9-A293-4A2B-9C44-EB939F26205A@webweaving.org> In-Reply-To: <1531317515.66719.20.camel@freebsd.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 11 Jul 2018, at 15:58, Ian Lepore <ian@freebsd.org> wrote: >=20 > 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=E2=80=99s design in PCB incarnation: >>=20 >> https://13-37.org/de/shop/infinite-noise-trng/ >>=20 >> Are there any caveats with regard to volume or speed of doing so ? Or >> is it always a plus ?=20 >>=20 >> Actual code at https://github.com/dirkx/infnoise/blob/master/software >> /libinfnoise.c line 122: >>=20 >> if ((devRandomFD =3D open("/dev/random",O_WRONLY)) <0) >> .. error handling >>=20 >> if (write(devRandomFD, bytes, length) !=3D length)=20 >> .. error handling >>=20 >> And is there any case where length would not return the length >> written =E2=80=94 it seems that the driver traps/ignores EINT, EAGAIN = and >> short writes ?=20 >>=20 >> 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). >>=20 >> With kind regards, >>=20 >> Dw >=20 > 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. >=20 > 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 =E2=80=94 but quell = that stream by a factor thousand. Dw.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA8D22E9-A293-4A2B-9C44-EB939F26205A>