Date: Sun, 23 Sep 2012 14:59:45 +0100 From: RW <rwmaillists@googlemail.com> To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: freebsd-security@freebsd.org Subject: Re: Collecting entropy from device_attach() times. Message-ID: <20120923145945.13d148e3@gumby.homeunix.com> In-Reply-To: <86lig3arpb.fsf@ds4.des.no> References: <20120918211422.GA1400@garage.freebsd.pl> <867grqm3pt.fsf@ds4.des.no> <20120919184758.28589516@gumby.homeunix.com> <86sjadt677.fsf@ds4.des.no> <20120920230133.55b63dea@gumby.homeunix.com> <86lig3arpb.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Sep 2012 01:20:32 +0200 Dag-Erling Sm=F8rgrav wrote: > RW <rwmaillists@googlemail.com> writes: > > They key will therefore *accumulate* entropy across multiple > > reseeds. >=20 > Forgot to address this. By definition, there can never be more > entropy in Yarrow than the key size. So it *does* throw away entropy > in the sense that if it accumulated, say, 900 bits of entropy > pre-boot (to pick one of the numbers Pawel cited), 650 of them are > wasted. I got fed up up of adding "up to 256 bits" and thought I could take it as read. Since the generator can only hold 256 bits and is secure well under that it doesn't really matter very much. Yarrow can't really be said to waste entropy since replacing entropy in the generator in a controlled way is what give it its ability to recover from compromise and break state extension attacks. If we're going to be pedantic it's only the generator that's limited to 256 bits, yarrow as a whole can accumulate up to 3x256 bits because the pools are not cleared on reseeds. There is some slight advantage in this, for example it means that two consecutive keys can be completely independent even on a fast reseed with a low value of kern.random.yarrow.fastthresh.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120923145945.13d148e3>