From owner-freebsd-security@FreeBSD.ORG Thu Sep 13 22:01:52 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67039106564A for ; Thu, 13 Sep 2012 22:01:52 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DECDD8FC14 for ; Thu, 13 Sep 2012 22:01:51 +0000 (UTC) Received: by weyx56 with SMTP id x56so2351193wey.13 for ; Thu, 13 Sep 2012 15:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=kjpl1pxAZ9LpcrH3azIlLs3k6iK0B1Se04pu6YlYEZg=; b=AByAk4fFASH8fxmuk1KudC/ATlPHvFaulqr+I3dNqAt9Sl91Q+qt4tjWkoRppcJ+/0 7cRw0Y8oI6z9lFJ2PgkmsUAlgVioxUq6anoani2xw65x0/P30ubyGKNwB7w8SkVFBC+s 0dCReFssmx+FeWd+reZhZivAFJAcGUke5jID2pcbnZfWFBHI6qbByYg2Gw4X7LjGZfYY +g4XBOWoMBoV72jTvHUB5CKXZB43LkyrTMalLXzlOVTfQStt4zKOn1Xp/cd8Wbu3MmFz eyhZ6lybJ+FpjRmi7p/38eP56LPgH39Ys/m88sBB4593OEiBbqekBSVF7P6d+mQUFdKv +wAQ== Received: by 10.180.77.34 with SMTP id p2mr43240143wiw.0.1347573710773; Thu, 13 Sep 2012 15:01:50 -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 hv8sm15938373wib.0.2012.09.13.15.01.48 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 15:01:49 -0700 (PDT) Date: Thu, 13 Sep 2012 23:01:47 +0100 From: RW To: freebsd-security@freebsd.org Message-ID: <20120913230147.6bee3b41@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 Subject: Re: svn commit: r239569 - head/etc/rc.d X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 22:01:52 -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.