Date: Mon, 3 Sep 2012 14:46:38 -0700 From: Arthur Mesh <arthurmesh@gmail.com> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org>, "David E. O'Brien" <obrien@FreeBSD.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <20120903214638.GO1464@x96.org> In-Reply-To: <50451D6E.30401@FreeBSD.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 03, 2012 at 02:13:18PM -0700, Doug Barton wrote: > > Yes, except /entropy is generated after /var/db/entropy/* and old > > /entropy was fed in to yarrow. So I don't believe saying it's poorly > > seeded at that point is fair. > > It is certainly not likely to be well seeded at that point, especially > on low end systems. Being seeded with /var/db/entropy/* and /entropy can be considered well seeded, unless you're talking about first boot time. /var/db/entropy/* and /entropy contain entropy from all the entropy collected throughout lifetime of the box. In the best case, they provide 4k + (8*2k) of entropy, assuming each bit provides a bit of entropy. That's plenty enough, given the fact that 128bit of entropy is what's recommended to be seeded with. > > > On next reboot /entropy will get re-written anyway. > > ... which illustrates my point that at best the change is superfluous. I don't believe it's superfluous. I've mentioned a real case where it is an improvement. > > >> IMO both of those are bad ideas, and lower both the quantity and quality > >> of the entropy available at the next boot, should that happen prior to > >> the (again, by default) 88 minutes it takes for the system to update > >> /var/db/entropy. > > > > You're still assuming that feeding the same entropy files in on > successive boots is a problem, which hasn't been proven yet. Yes, in this case, I am assuming the worst case scenario. Perhaps it has not been proven, but I don't think waiting until it is proven is a good idea. Especially since the fix for the potential problem is simple. Also, please consider the fact that Schneier explicitly recommends against reusing same entropy seed files... Consider a system where hardware entropy is disabled (silly but could simulate a case of low-end systems). If I reuse same seed files, I will end up with same exact state of yarrow on both bootups. Bet you if you try to generate RSA SSH hostkeys, you'll end up with identical ones on as in previous boot. > Right, which is why we rotate the files in /var/db/entropy, and write > out a new /entropy file as part of the shutdown process. I'm not > disagreeing with your premise that new/different entropy files _should_ > be used. I'm disagreeing with your premise that deleting/replacing the > old ones at boot time is an improvement. I've mentioned a real case where it is an improvement. > > > Also, our findings have shown that on some very low end systems, these > > seed files are pretty much the only source of entropy early during boot. > > But the fact that on these low end/embedded systems there is very little > entropy available at boot time actually makes it more important that we > don't delete what little we have. I am not simply discarding "little we have". It's seeded in to yarrow before we generate a new /entropy. Thus, for attacker to replicate /entropy, she would probably need to reconstruct "little we had" in the first place.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120903214638.GO1464>