On Wed, 19 Sep 2012 20:59:15 +0100 Ben Laurie wrote: > On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek > <[email protected]> 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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"