From owner-freebsd-rc@FreeBSD.ORG Mon Sep 3 21:13:19 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 1001D106566B; Mon, 3 Sep 2012 21:13:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 931A014E99E; Mon, 3 Sep 2012 21:13:18 +0000 (UTC) Message-ID: <50451D6E.30401@FreeBSD.org> Date: Mon, 03 Sep 2012 14:13:18 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Arthur Mesh References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> In-Reply-To: <20120903203505.GN1464@x96.org> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray , "David E. O'Brien" Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 21:13:19 -0000 On 09/03/2012 13:35, Arthur Mesh wrote: > On Mon, Sep 03, 2012 at 01:12:26PM -0700, Doug Barton wrote: >> I didn't miss it. What postrandom does is delete all of the (by default) >> 8 files in /var/db/entropy that were the product of the previous boot's >> output. Then it re-generates /entropy, which was written out at the last >> shutdown, ideally after enough uptime for /dev/random to have been >> properly seeded, with a new file generated from a poorly seeded entropy >> pool as part of the boot process. > > 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. > On next reboot /entropy will get re-written anyway. ... which illustrates my point that at best the change is superfluous. >> 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. > > I believe this is better than what we have today, since it prevents a > case where system crashes before cronjob (that writes to > saved-entropy.X) gets to run at all. This patch reduces this window to > matter of a second or so. You're still assuming that feeding the same entropy files in on successive boots is a problem, which hasn't been proven yet. > If you think quantity is very important here, (which I don't believe is > true) I am fine with not deleting /var/db/entropy/* on boot (It doesn't > make things better or worse). > >>> In the end, assuming machine boots up passed postrandom script, we're left with >>> no stale seed files, but a freshly generated ${entropy_file_confirmed}, which >>> should be sufficient to seed next bootup. > >> I understand how you're thinking about this, but unfortunately I'm quite >> certain your thinking is incorrect. As I pointed out in my last message, >> Yarrow is designed to cope with the possibility of replay attacks, and >> even with feeding in the same entropy files (after a short boot) the >> amount of new material we introduce at each boot fully alleviates this >> concern. > > You could be correct about Yarrow, but the Bruce Schneier explicitly > recommends to recycle already used seed with a new one. Reference is > provided in the code. 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. > 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. Hopefully you saw Ian's report along that line. I'm sensitive to the idea of certain low end systems not providing a whole lot of entropy from the commands that are fed in as part of the "better than nothing" process. But it's also useful to note that rc.d/initrandom starts the hardware entropy harvesting process as well, so even though we're not getting a lot of entropy from the "better than nothing" commands we're still stirring the pool with new material early in the boot process. 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. > Moreover, we also uncovered other problems with the way things are > consumed by Yarrow via /dev/random. > We will provide more details on our findings a bit later. Please do ... probably security@ is the right forum for that. Sooner than later if you think that it affects the rc.d related discussion. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909)