Date: Sat, 15 Sep 2012 12:41:51 +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: <CAG5KPzxOua1t%2BWCef77E5jA1j_m6faw3JXUgsy8W_TeE%2BkpLUg@mail.gmail.com> In-Reply-To: <E1TCqDg-000N6O-Nv@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> <CAG5KPzwEESg7iUb2%2B-kAN%2Bk55M95BZjh5VaSvxzSsSCVuZ9kMw@mail.gmail.com> <E1TCdlD-000C1N-4g@groundzero.grondar.org> <CAG5KPzzFO1H5Wcx34oXi09=aJqg5w%2BXWSd8fnn0Byvpy_8%2B-rA@mail.gmail.com> <E1TCpk1-000N2H-Vq@groundzero.grondar.org> <CAG5KPzym9ahG5B6-9JyzWJ-PRy43u1dAuk%2B6185mvxKOpJkr7g@mail.gmail.com> <E1TCqDg-000N6O-Nv@groundzero.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 15, 2012 at 12:07 PM, Mark Murray <markm@freebsd.org> wrote: > Ben Laurie writes: >> > Are you aware of Yarrow's approach to poor entropy while harvesting? >> >> Yes. I am _only_ talking about fixes for the current practice of >> discarding input - once Yarrow gets to eat input, then its all fine, >> but as you say, you don't want to run Yarrow over all input because it >> is too expensive. > > Correct. > >> So, you plan to xor input with itself, instead of discarding if it >> fills the buffer. My point is that unfortunate choice of input can >> result in the input cancelling itself out. > > That means that diverse input should be used, and that is the intent > anyway. > > Hashing _certain_ input in /etc/rc.d/initrandom is also attractive. > >> This is not part of Yarrow - Yarrow specifies that you hash all >> inputs, not xor or discard them :-) > > Beyond nitpicking. How the data is harvested is not discussed in much > detail. It says that the pools contain the running hash of all inputs fed to them since they were last used to reseed. It is _not_ "beyond nitpicking" to observe that neither xor nor discard are hashing. _Particularly_ when you suggest that my criticism arises from ignorance of Yarrow! The whole point of Yarrow is to extract all available entropy by the use of hash functions. If you do something else, then you are not doing Yarrow. That said, as I understand your proposed code, what you are doing is xoring each complete input into a HARVESTSIZE buffer, then submitting that as an event - so the problem only arises if a single input repeats internally. It might be a good idea, assuming we go down this path, to add a note to the man page pointing out that: cat a > /dev/random cat b > /dev/random is wiser than: cat a b > /dev/random I remain surprised that the cost of hashing the input into a HARVESTSIZE buffer is noticable after all the other costs of the system call, though. > Here, I'm chunking the file input up, instead of taking it > piecemeal. In each case, the harvested data is handed over to Yarrow as > a series of data "events". Keystrokes, mouse events, interrupts or uio() > calls are all such events, and many more are possible as input. I notice that events are also discarded when the queue reaches a certain length. This seems like a problem, too.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5KPzxOua1t%2BWCef77E5jA1j_m6faw3JXUgsy8W_TeE%2BkpLUg>