From owner-freebsd-hackers@freebsd.org Wed Jul 11 14:35:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8588010436FB for ; Wed, 11 Jul 2018 14:35:49 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "weser.webweaving.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC7B074D75 for ; Wed, 11 Jul 2018 14:35:48 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6BEYTaS004062 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Jul 2018 16:34:30 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Limits to seeding /dev/random | random(4) From: Dirk-Willem van Gulik In-Reply-To: <1531317515.66719.20.camel@freebsd.org> Date: Wed, 11 Jul 2018 16:34:29 +0200 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (weser.webweaving.org [148.251.234.232]); Wed, 11 Jul 2018 16:34:30 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 14:35:49 -0000 > On 11 Jul 2018, at 15:58, Ian Lepore 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.=