Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Sep 2012 11:51:57 +1000
From:      Peter Jeremy <peter@rulingia.com>
To:        freebsd-security@freebsd.org, freebsd-rc@freebsd.org
Cc:        Arthur Mesh <arthurmesh@gmail.com>, Doug Barton <dougb@freebsd.org>, Mark Murray <markm@freebsd.org>, obrien@freebsd.org, RW <rwmaillists@googlemail.com>, Xin Li <delphij@delphij.net>
Subject:   Re: svn commit: r239569 - head/etc/rc.d
Message-ID:  <20120907015157.GA29497@server.rulingia.com>
In-Reply-To: <20120906224703.GD89120@x96.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <delphij@delphij.net> 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 <arthurmesh@gmail.com> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120907015157.GA29497>