Date: Thu, 12 Jul 2018 10:32:03 -0700 From: Conrad Meyer <cem@freebsd.org> To: Dirk-Willem van Gulik <dirkx@webweaving.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: <CAG6CVpX1DnB7KDigG=wMPROM6vvdw0LB005u6d3c29Dbp7NhTw@mail.gmail.com> In-Reply-To: <7C42CD28-078F-4AF6-90F2-5E951F8386D5@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >> >>> 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. >> >> This is a bit simplistic because it ignores the way that fortuna >> stripes entropy across 32 pools. 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 :-). >> 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 rando= m >> device. This should be done as early in the rc.d boot process as >> possible. 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. >> Once the pools are primed you could trickle entropy in in >> smaller amounts if you wish. Right =E2=80=94 that's what Ian is suggesting. > So these HW devices [1] give us a raw feed =E2=80=94 which one usually wh= itewashes [2] in order to use. Don't feed the raw data =E2=80=94 use the washed bits. > It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2= =80=99. > > 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 f= or example the mouse driver) ? 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. > Or should it be properly whitened first ? Yes :-). > Our goal is to get to a point where a very stripped down BSD can be boote= d up (sans network or much in terms of attached devices but for a printer a= nd chipcard reader) =E2=80=94 yet is know to have a solid seeded RNG. /dev/u?random never produces unseeded results. If it is not seeded, reads will just block indefinitely, until it is seeded. 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. All the best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpX1DnB7KDigG=wMPROM6vvdw0LB005u6d3c29Dbp7NhTw>