From owner-freebsd-rc@FreeBSD.ORG Thu Sep 13 22:06:01 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 CD9F5106564A; Thu, 13 Sep 2012 22:06:01 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BFC748FC08; Thu, 13 Sep 2012 22:06:00 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2627850wgb.31 for ; Thu, 13 Sep 2012 15:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=31KZdxiuB5tT10a1Xst67UBXvqBbqeG7Q8M6W6uSQLg=; b=sxrESyh5pYWl3tCBCvxN8OGIvB7gwU6zOV2cpxjwJoW+246FqV5lxAAgfGpz7lnV5b UPSYRvQ1Nt+tnIUU3udwuc+wWvra9E9Qlz2CqnysIuAoVI8ZD9Z5qxwWYKVbFCs9aSFk 9NjCeveCWSPZvRR6tPGG2it3ph9zi3mTbTKzaZU1QWrsnUh9DhJ1EYPVjZNn1UE78c2g We0bWPBfhSPkP2Afgc+LJvFF6/8CTo5n8zeFzOVZPMuw7tKmwvcrpIuGtLtoF86n8U75 b4KXLOcF1+G8UfrFjW8U/W27BbzUNXdQG7UFxn8iTKU9OVIPXikUJylYF428AACvbGIa hk3g== Received: by 10.180.81.99 with SMTP id z3mr591027wix.0.1347573954221; Thu, 13 Sep 2012 15:05:54 -0700 (PDT) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id fb20sm23478266wid.1.2012.09.13.15.05.52 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 15:05:53 -0700 (PDT) Date: Thu, 13 Sep 2012 23:05:51 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120913230551.7f299ffc@gumby.homeunix.com> In-Reply-To: References: <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> <20120907015157.GA29497@server.rulingia.com> <20120910135218.GA68128@dragon.NUXI.org> <504E343A.4020802@FreeBSD.org> <20120911064636.GB72584@dragon.NUXI.org> <504EE446.6060500@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <20120912104547.1d0061c1@gumby.homeunix.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , Doug Barton , freebsd-rc@freebsd.org, obrien@freebsd.org, Xin Li 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: Thu, 13 Sep 2012 22:06:02 -0000 On Thu, 13 Sep 2012 20:00:19 +0100 Mark Murray wrote: > > The entropy estimated at zero bits is so that an *unpriveleged* user > > can't feed in his own input, corrupt the entropy estimation and > > perform a state-extension attack. > > Yarrow is pretty resistant to this. "cat /dev/zero > /dev/random" > won't "dilute" the gathered entropy,... FWIW the theory is that if an attacker can insert known data that has a non-zero entropy estimation then they might repeatedly bring forward reseeds resulting in the entropy from other sources being dribbled into the generator in insecure amounts. > > On Tue, 11 Sep 2012 00:12:06 -0700 Doug Barton wrote: > > > > > I'm also tired of repeating why writing out a new /entropy file at > > > boot time makes the system weaker, not stronger. > > > > That's not really true. The entropy file contains up to 256 bits of > > entropy, if yarrow is correctly seeded with that then that entropy > > will be in the 256-bit key which will produce a new file that also > > contains that entropy. > > Too many /entropy.* files would be overkill, but done properly, won't > hurt. The discussion was about replacing the single /entropy file, not having many files. > The harvest queue (as pointed out) is limited, and its possible to > overwhelm it with excessive input. I'm in favour of doing something > to "dribble" the startup suff in, while limiting its length to (say) > 1-2 K. There are two possibilities here depending on whether you close the device between dribbles or keep it open. In the former case you're repeatedly forcing reseeds and clearing the entropy counters - dribbling entropy into the generator is precisely what Yarrow was designed to avoid. In the latter case you either have to block the boot, which will be unpopular, or dribble in the background in which case it may be too late. For example geli keys for encrypted swap are generated almost immediately after initrandom. Ideally everything should go in in a single write, as early as possible, and Yarrow should be left to work the way it was designed to work. > Compressing the gathered stuff is a good idea, Compression is a very bad idea, it uses more CPU cycle as sha256 without guaranteeing an output that fits comfortably into 4kB.