Date: Wed, 5 Sep 2012 02:12:48 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-security@freebsd.org Subject: Re: svn commit: r239598 - head/etc/rc.d Message-ID: <20120905021248.5a17ace9@gumby.homeunix.com> In-Reply-To: <50468326.8070009@FreeBSD.org> References: <201208222337.q7MNbORo017642@svn.freebsd.org> <5043E449.8050005@FreeBSD.org> <20120904220126.GA85339@dragon.NUXI.org> <50468326.8070009@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 04 Sep 2012 15:39:34 -0700 Doug Barton wrote: > and given what Yarrow does to > obfuscate the internal entropy state I'm not confident that hashing > the input is either necessary or desirable. All of the low-grade entropy should go through sha256. Anything written into /dev/random is passed by random_yarrow_write() 16 Bytes at time into random_harvest_internal() which copies it into a buffer and queues it up. If there are 256 buffers queued random_harvest_internal() simply returns without doing anything. The yarrow kernel thread moves all of the entropy queues into a local queue, processes that queue and then pauses for 100ms and loops. That means that each time around the loop only a maximum of 4096 bytes can be processed. Anything after that is discarded. It seems very likely that /entropy is completely discarded most of the time, which means that the first 4096 bytes of " ps -fauxww ; sysctl -a" is the only entropy that makes it through to yarrow, and that's practically nothing. On a sufficiently fast system the entropy buffers may still be saturated when rc.d/random runs, so in theory they could be lost too. And embedded doesn't necessarily imply slow. I'm not overly concerned about this because anything that doesn't generate enough entropy naturally, increasingly tends to have a hardware generator, but it's easy to fix it, so it should be fixed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120905021248.5a17ace9>