Date: Thu, 12 Jul 2018 19:42:24 +0200 From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: cem@freebsd.org Cc: RW <rwmaillists@googlemail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Limits to seeding /dev/random | random(4) Message-ID: <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> In-Reply-To: <CAG6CVpX1DnB7KDigG=wMPROM6vvdw0LB005u6d3c29Dbp7NhTw@mail.gmail.com> 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> <CAG6CVpX1DnB7KDigG=wMPROM6vvdw0LB005u6d3c29Dbp7NhTw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jul 2018, at 19:32, Conrad Meyer <cem@freebsd.org> wrote: > On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik > <dirkx@webweaving.org> wrote: >> On 12 Jul 2018, at 17:57, RW via freebsd-hackers = <freebsd-hackers@freebsd.org> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55685C1F-4711-40C7-8EB4-2930BF8C9884>