From owner-freebsd-rc@FreeBSD.ORG Mon Sep 3 21:46:44 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4684C106564A; Mon, 3 Sep 2012 21:46:44 +0000 (UTC) (envelope-from arthurmesh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF9F08FC15; Mon, 3 Sep 2012 21:46:43 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so8462952pbb.13 for ; Mon, 03 Sep 2012 14:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WWaJC4ut+yrJgKTKOGbORNmc38vQJlI4MqrU4RUPkLY=; b=ZlvZJh03qHe7NM/lLz9TNDwnIOmKK4xYjw1ZEwLxp2qK4lCKaSAl7lr8Kg2pxThbRQ eXxHvNCJm6OP8eAjFHDvXL/dXeu4oZu7fNFjmntXt6QEAL3KX0D67+53V/FHh+AJ6pc3 4Xip2z+7HZLeA+ekOSPUQOlq/Q9jrLo0W3xStsm+7jdgFV8fopTzbbiJb6YMzKIJi65k hk/71gBCj0Fy/ygkgs1dWZ/wAk3RmrAMlTffhME51YMuBzQ9b5NRJMcfBaf5iEWH34Us 3Pj3/TP/h9w/Lun7SrklxiYT4nMLtJRwBpO6tq+fUyABEqEq/GNf/n33pnyQLqhfYOzn WxJw== Received: by 10.68.136.137 with SMTP id qa9mr40592612pbb.140.1346708803533; Mon, 03 Sep 2012 14:46:43 -0700 (PDT) Received: from x96.org (x96.org. [64.85.165.177]) by mx.google.com with ESMTPS id vf8sm10661729pbc.27.2012.09.03.14.46.41 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 14:46:42 -0700 (PDT) Date: Mon, 3 Sep 2012 14:46:38 -0700 From: Arthur Mesh To: Doug Barton Message-ID: <20120903214638.GO1464@x96.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50451D6E.30401@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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:46:44 -0000 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.