Date: Wed, 19 Sep 2012 21:46:24 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-security@freebsd.org Subject: Re: Collecting entropy from device_attach() times. Message-ID: <20120919214624.2f6682a2@gumby.homeunix.com> In-Reply-To: <CAG5KPzyxSMZ8X4RmEhCHA=dHTLUw5mOUf-oveJtOPx8im3dpeQ@mail.gmail.com> References: <20120918211422.GA1400@garage.freebsd.pl> <A8FD98DD94774D00B4E5F78D3174C1B4@gmail.com> <20120919192923.GA1416@garage.freebsd.pl> <CAG5KPzyxSMZ8X4RmEhCHA=dHTLUw5mOUf-oveJtOPx8im3dpeQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Sep 2012 20:59:15 +0100 Ben Laurie wrote: > On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek > <pjd@freebsd.org> wrote: > > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote: > >> > If all the times are more or less equally probable in this range > >> > […] > >> > >> They're very unlikely to be equally probable. It would make sense > >> to do some characterization of these times and their statistics: a > >> highly non-uniform distribution would mean that we don't actually > >> get many bits per attach. > > > > I have times for ~2000 device_attach() calls when loading sound card > > driver on totally idle system. If someone could take those and > > analyse the distribution that would be great. > > > >> > […] we have more > >> > than 19 bits of entropy from this one call, but I reduced if to > >> > four bits only, because there are devices that are much faster > >> > to attach. > >> > > >> > >> Another reason for doing the above characterization is that, if a > >> particular device_attach() really does provide 12 bits of > >> uncertainty, it's a shame to drop eight of them on the floor. > > > > Rights. That's why I've prepared another patch: > > > > http://people.freebsd.org/~pjd/patches/harvest_device_attach.2.patch > > > > which effectively discards top ten bits, which means we expect 0.1% > > of the attach time to be unpredictable (the attach time in most > > cases vary by few percent, not sure yet how much of this variation > > is really unpredictable). > > This is the wrong thing to do! There's no reason to discard bits on > input (modulo the device throwing away inputs, that is) - just reduce > your entropy estimate. "Extra" bits do no harm. Not only that but the actual full entropy will get used because initrandom forces a reseed irrespective of the current accounting. The extra bits may make the difference between secure and insecure The entropy estimations before that are of no significance unless you have a local attacker that early in the boot.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120919214624.2f6682a2>