Date: Fri, 14 Sep 2012 22:01:15 +0100 From: Ben Laurie <benl@freebsd.org> To: Mark Murray <markm@freebsd.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, Ian Lepore <freebsd@damnhippie.dyndns.org>, Doug Barton <dougb@freebsd.org>, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>, "Bjoern A. Zeeb" <bz@freebsd.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <CAG5KPzwEESg7iUb2%2B-kAN%2Bk55M95BZjh5VaSvxzSsSCVuZ9kMw@mail.gmail.com> In-Reply-To: <E1TCcIq-000Brr-Ex@groundzero.grondar.org> References: <50453686.9090100@FreeBSD.org> <20120911082309.GD72584@dragon.NUXI.org> <504F0687.7020309@FreeBSD.org> <201209121628.18088.jhb@freebsd.org> <5050F477.8060409@FreeBSD.org> <20120912213141.GI14077@x96.org> <20120913052431.GA15052@dragon.NUXI.org> <alpine.BSF.2.00.1209131258210.13080@ai.fobar.qr> <alpine.BSF.2.00.1209141336170.13080@ai.fobar.qr> <E1TCXN0-000NFT-7I@groundzero.grondar.org> <CAG5KPzwOdCkybj3D5uic1KC-pwW-pewgsrqrXg60f5SJjtzYPw@mail.gmail.com> <E1TCbDG-0002Hz-9D@groundzero.grondar.org> <CAG5KPzzRxzVX-%2B9fYjRdqjY-wScbM6AA7GYtLmktgMG0Zg8iyQ@mail.gmail.com> <E1TCbSz-0007CJ-BI@groundzero.grondar.org> <CAG5KPzyJNmXRfxtPPrdc2zVCsxGtDfJT79YC3a1PNUfOOSzt8A@mail.gmail.com> <E1TCcIq-000Brr-Ex@groundzero.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 14, 2012 at 9:15 PM, Mark Murray <markm@freebsd.org> wrote: > Ben Laurie writes: >> What I am trying to do is extract whatever entropy there is in the >> input. You appear to be saying that there's no point adding extra >> entropy because it is estimated at zero. This makes no sense to me. > > What I am trying to say is that it doesn't matter if by some coincidence > certain harvested file fragments contain zero. Furthermore, it doesn't > matter if you feed /dev/random a whole bunch of zeros (except in the > case where that swamps out other harvested events, and it is that > problem we are trying to solve, amonmgst others). I agree with this. > My proposed solution is intended so address, if not solve that problem, > by preventing file writes from filling up the harvest queue. Yarrow > already has pretty good data hashing; there is no point in duplicating > that. Fine: then when the queue fills, run the Yarrow algorithm. If not, then whatever you run instead must also be sound. XOR isn't. > Note that I have already agreed that external preconditioning of the > data is a good idea; I like the idea of compression and some external > hashing (but not the speed of these duting boot). I don't, because you can't rely on it. That is, I'm not against it, but we can't rely on it. > Others may work, but > ultimately I trust Yarrow more. > > M > -- > Mark R V Murray > Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) > Pi: 132511160 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5KPzwEESg7iUb2%2B-kAN%2Bk55M95BZjh5VaSvxzSsSCVuZ9kMw>