From owner-freebsd-rc@FreeBSD.ORG Fri Sep 7 01:52:17 2012 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C5D6106564A; Fri, 7 Sep 2012 01:52:17 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4575A8FC0A; Fri, 7 Sep 2012 01:52:16 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q871q356076012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Sep 2012 11:52:04 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q871pvVa033740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 11:51:58 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q871pvXm033739; Fri, 7 Sep 2012 11:51:57 +1000 (EST) (envelope-from peter) Date: Fri, 7 Sep 2012 11:51:57 +1000 From: Peter Jeremy To: freebsd-security@freebsd.org, freebsd-rc@freebsd.org Message-ID: <20120907015157.GA29497@server.rulingia.com> References: <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20120906224703.GD89120@x96.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arthur Mesh , Doug Barton , Mark Murray , obrien@freebsd.org, RW , 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: Fri, 07 Sep 2012 01:52:17 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Sep-06 12:17:40 -0700, Xin Li wrote: >On 09/06/12 11:21, David O'Brien wrote: >> At this point I am liking: sysctl kern.cp_times kern.cp_time >> kern.lastpid kern.timecounter \ kern.tty_nout kern.tty_nin vm vfs >> debug dev.cpu \ | tr -Cd '0123456789xabcdef' > >I think you could use sysctl -n to remove the variable names (which is >a good thing). That seems reasonable. > I'm a little bit concerned with the fact that most of >the characters here are numbers, would it be a good idea to filter it >with e.g. gzip (my $.02) by the way before feeding into /dev/random? Given that /dev/random can only cope with 4KB/write and 10 writes/sec before it starts discarding input, some sort of compression function is worthwhile. My gut feeling is that gzip won't lose entropy, though a hashing function could. I've done some experiments on a couple of systems to look at gzip and sha256 speed. On one box, "sysctl -an" returns 109989 bytes (though it has been up for a while) which gzip's to 12511 bytes (still too large for a single write to /dev/random). The following is the wallclock time to run sha256 or gzip on that input (based on multiple runs of 100 loops). sha256 gzip -6 CPU 3.3ms 5.9ms 2.5GHz amd64 (Athlon 4850e) 6.8ms 13.3ms 1.6GHz i386 (Atom N270) 85 ms 34 ms 700MHz ARMv6 (Raspberry PI, running Linux) These times are all in the noise compared to overall startup time. On 2012-Sep-06 15:47:03 -0700, Arthur Mesh wrote: >On Thu, Sep 06, 2012 at 11:01:57PM +0100, RW wrote: >> Reusing a secure entropy file is only a problem if the complete history >> of yarrow, from boot until some significant output, is exactly the same >> as on a previous boot. > >Not sure I agree. It's not the only problem. It's the worst problem; >in the situation you describe, you'll end up with identical output from >/dev/random. I don't believe this is possible in practice for two reasons: 1) Yarrow starts collecting entropy from hardware devices as soon as it initialises. It will already have some entropy before init(8) is started and will be gathering more as rc scripts run. 2) Inputs to /dev/random are tagged with a high-resolution timestamp. I don't believe this runs at less than 1MHz on any platform and will typically run at >>100MHz. In order to reproduce the state, you need to feed the same input in with sub-microsecond timing. And this all occurs well before user logins are allowed. If you have an attacker that can tightly control what happens during early system startup, you have more serious problems than the amount of entropy in /dev/random. --=20 Peter Jeremy --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBJUz0ACgkQ/opHv/APuIcgIwCgvlNkCyioy7uOYrM+kM6PVLCz kKkAniqCPanegQiytiBiV2Cs70f1eY9n =0+Aa -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C--