Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Sep 2012 17:31:53 +0100
From:      Ben Laurie <benl@freebsd.org>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        Arthur Mesh <arthurmesh@gmail.com>, Doug Barton <dougb@freebsd.org>, freebsd-rc@freebsd.org, freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com>, Dag-Erling ??? <des@des.no>, d@delphij.net
Subject:   Re: svn commit: r239569 - head/etc/rc.d
Message-ID:  <CAG5KPzxzf5EWK13Qqb73jD3ogN4QGCU9TOGw1nvNQstpCLRfUQ@mail.gmail.com>
In-Reply-To: <20120914153030.GA2146@garage.freebsd.pl>
References:  <86sjao7q8c.fsf@ds4.des.no> <20120911205302.27484fd6@gumby.homeunix.com> <20120911200925.GA88456@dragon.NUXI.org> <504FA76A.5000209@delphij.net> <20120911211730.GB89188@dragon.NUXI.org> <504FAB87.3020701@delphij.net> <20120911215212.GA89515@dragon.NUXI.org> <504FBD15.8040907@delphij.net> <20120911224855.GE14077@x96.org> <504FC2BD.6070402@delphij.net> <20120914153030.GA2146@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 14, 2012 at 4:30 PM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:
> On Tue, Sep 11, 2012 at 04:01:17PM -0700, Xin Li wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 09/11/12 15:48, Arthur Mesh wrote:
>> > On Tue, Sep 11, 2012 at 03:37:09PM -0700, Xin Li wrote:
>> >> Using gzip is better than not using it though, since 4k worth of
>> >> compressed data is better than 4k worth of plain text because of
>> >> higher entropy destiny (note that the FreeBSD gzip uses 64K of
>> >> input/output buffer for compression by the way so maybe only the
>> >> first 64K is meaningful if we take only 4k of output).
>> >
>> > Since there is 1:1 correspondence between compressed and
>> > uncompressed data, entropy should be the same in both. I am not
>> > sure it's better to use compression than not -- you do end up
>> > seeding fewer bytes to yarrow, but you spend more CPU cycles
>> > compressing it...
>>
>> Well, 1:1 correspondence is when we fed full text to /dev/random,
>> which we don't, right?  Only the first 4K gets consumed.  So:
>>
>> Situation 1: we have 45K of plain text, and only first 4k is fed to
>> /dev/random at about 5 bits of entropy per byte;
>
> 5 bits of entropy per byte from 'sysctl -a' output??? Xin, you are way,
> way too optimistic. This is plain text, so one bit is mostly unused, so
> we have 7 usable bits. Out of those 7 bits you claim that 5 on averge is
> unpredictable? In other words do you think 5/7 (~71%) of this output is
> unpredictable? It would be great if 1% would be unpredictable, but I
> highly doubt it. But this is not the point, the point is to colect at
> least 128 bits in total from those 45kB, so ~0.28% of unpredictable
> output would be enough if we can of course feed everything into yarrow.
>
> Also, compression can definiately increase entropy per byte, but IMHO it
> can also lose some entropy overall. With lossless compression you don't
> lose data, but I don't believe you can say that you don't lose entropy.

Entropy is something with multiple definitions, but for our purposes
it really means "how big is the universe of possible states we just
chose from?". More or less. Compression does not change this.

> I don't recall who said this (Arthur?), but I fully agree that we should
> fix yarrow, /dev/random or whatever is dropping the input after 4kB.

Many people have said it :-) I completely agree!

> If we can't do that, then we should hash it with sha512 this way the
> entropy will be reduced to 512 bits (if there is more entropy in the
> input) which should be enough for yarrow to be happy.
>
> Also note that gzip is currently in /usr/bin/ and /usr/ might not be yet
> mounted when we do that.
>
> --
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> FreeBSD committer                         http://www.FreeBSD.org
> Am I Evil? Yes, I Am!                     http://tupytaj.pl



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