From owner-freebsd-hackers@freebsd.org Thu Jul 12 17:43:45 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 DB523102BD7B for ; Thu, 12 Jul 2018 17:43:44 +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 6B8FC755F1 for ; Thu, 12 Jul 2018 17:43:44 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id w6CHgQZN047526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Jul 2018 19:42:26 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] 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: Date: Thu, 12 Jul 2018 19:42:24 +0200 Cc: RW , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> To: cem@freebsd.org 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]); Thu, 12 Jul 2018 19:42:26 +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: Thu, 12 Jul 2018 17:43:45 -0000 On 12 Jul 2018, at 19:32, Conrad Meyer wrote: > On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik > wrote: >> On 12 Jul 2018, at 17:57, RW via freebsd-hackers = wrote: >>> On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: >>>=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. 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. >>>=20 >>> This is a bit simplistic because it ignores the way that fortuna >>> stripes entropy across 32 pools. >=20 > 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=3D8192 bits into the = random >>> device. This should be done as early in the rc.d boot process as >>> possible. >=20 > 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. >=20 >>> Once the pools are primed you could trickle entropy in in >>> smaller amounts if you wish. >=20 > Right =E2=80=94 that's what Ian is suggesting. >=20 >> So these HW devices [1] give us a raw feed =E2=80=94 which one = usually whitewashes [2] in order to use. >=20 > Don't feed the raw data =E2=80=94 use the washed bits. >=20 >> It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2= =80=99. >>=20 >> 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) ? >=20 > 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 =E2=80=94 it'll take at most 90 ms to fully seed > /dev/random at that rate, even with a readonly filesystem > embedded-type device. >=20 >> Or should it be properly whitened first ? >=20 > 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) =E2=80=94 yet is know to have a solid = seeded RNG. >=20 > /dev/u?random never produces unseeded results. If it is not seeded, > reads will just block indefinitely, until it is seeded. As we=E2=80=99ve 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. =20 Thanks for that. Unfortunately we=E2=80=99re in a read-only situation. = And we=E2=80=99ve had CI testing yield identical results a few times = now. Dw.=