Its useless chink.
Sent from my iPhone
On Sep 14, 2012, at 11:39 PM, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 9/14/12 7:18 PM, Samuel Ports wrote:
>> Omg cant an freebsd-entropy be created as mailing list already
>
> Nothing prevents you from unsubscribing this m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 9/14/12 7:18 PM, Samuel Ports wrote:
> Omg cant an freebsd-entropy be created as mailing list already
Nothing prevents you from unsubscribing this mailing list.
> Sent from my iPhone
>
> On Sep 14, 2012, at 8:09 PM, RW
> wrote:
>
>> On Fri, 1
Omg cant an freebsd-entropy be created as mailing list already
Sent from my iPhone
On Sep 14, 2012, at 8:09 PM, RW wrote:
> On Fri, 14 Sep 2012 17:25:59 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 3:46 PM, RW
>> wrote:
>>> On Fri, 14 Sep 2012 14:43:53 +0100
>>> Ben Laurie wrote:
>>>
On Fri, 14 Sep 2012 22:49:14 +0100
Mark Murray wrote:
> If not, then whatever you run instead must also be sound. XOR isn't.
>
> You have a way to go before you convince me on this one. I'll buy this
> argument if it is a routine/regular/risky ocurrence that the output
> of (say)
>
> $ ( ps -gau
On Fri, 14 Sep 2012 16:15:03 -0700
Arthur Mesh wrote:
> Has it been considered that /dev/random being "rw-rw-rw-" may be a bad
> idea? What's the benefit of allowing unprivileged users reseeding
> yarrow? Perhaps restricting it to "rw-r--r--" is a part of the
> solution that may address potential
On Fri, Sep 14, 2012 at 10:49:14PM +0100, Mark Murray wrote:
> I can certainly trigger a reseed at will, but allowing external writes
> to overwhelm the system by doing a
>
> $ cat /dev/zero > /dev/random
>
> ... just ain't gonna happen. No, sir.
Has it been considered that /dev/random being "rw
On Fri, 14 Sep 2012 17:25:59 +0100
Ben Laurie wrote:
> On Fri, Sep 14, 2012 at 3:46 PM, RW
> wrote:
> > On Fri, 14 Sep 2012 14:43:53 +0100
> > Ben Laurie wrote:
> >
> >> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
> >> wrote:
> >> > 7) send all data to the kernel and hash (arch dependent?) i
Ben Laurie writes:
> > 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 Ya
On Fri, Sep 14, 2012 at 9:15 PM, Mark Murray 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 t
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
On Fri, Sep 14, 2012 at 8:22 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > What??! Have you seen how Yarrow does its harvesting??
>>
>> If you XOR into the as-yet-unharvested buffer, then appropriately
>> aligned repeated input makes the buffer zero.
>
I have no idea what point you're trying t
Pawel Jakub Dawidek writes:
> 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.
By definition (both the definition of entropy
Ben Laurie writes:
> > What??! Have you seen how Yarrow does its harvesting??
>
> If you XOR into the as-yet-unharvested buffer, then appropriately
> aligned repeated input makes the buffer zero.
There is an "if" and an "appropriately" in there. The entropy is
estimated as Zero anyway, in spite o
Ben Laurie writes:
> > I'll send patches (untested) in a couple of hours for discussion.
>
> I used to like this idea, but it can break pretty badly if you repeat
> input, so in the end I decided hashes were the only safe way.
What??! Have you seen how Yarrow does its harvesting??
Presupposing t
On Fri, Sep 14, 2012 at 8:06 PM, Mark Murray wrote:
> Ben Laurie writes:
>> > I'll send patches (untested) in a couple of hours for discussion.
>>
>> I used to like this idea, but it can break pretty badly if you repeat
>> input, so in the end I decided hashes were the only safe way.
>
> What??! H
On Fri, Sep 14, 2012 at 4:30 PM, Pawel Jakub Dawidek 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 b
On Fri, Sep 14, 2012 at 3:59 PM, Mark Murray wrote:
>> 5) send all data to the kernel but XORing the data together on
>> overflow in the kernel (can control when buffer full and only then
>> take action when needed, indepedent on how seed data is chosen,
>> withdrawn)
>
> I've already coded this u
On Fri, Sep 14, 2012 at 3:46 PM, RW wrote:
> On Fri, 14 Sep 2012 14:43:53 +0100
> Ben Laurie wrote:
>
>> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
>> wrote:
>> > 7) send all data to the kernel and hash (arch dependent?) it +
>> > counter value into the buffer on overflow, as in b[n] = H(b[n
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 d
"Bjoern A. Zeeb" writes:
> 1) continue to over-[fs]eed as we always did (seems out of question,
> no improvement)
See below. Solutions are very possible.
> 2) compress (as in gzip) the input of better_than_nothing (multiple
> people objected, no literature, questionable outcome, speed, still not
On Fri, 2012-09-14 at 13:38 +, Bjoern A. Zeeb wrote:
> On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
>
> Hi,
>
> I have removed freebsd-rc for this part of the discussion as it's
> unrelated.
>
I don't think I have the right expertise to help in this discussion. My
gut tells me that lossless
On Fri, 14 Sep 2012 14:43:53 +0100
Ben Laurie wrote:
> On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb
> wrote:
> > 7) send all data to the kernel and hash (arch dependent?) it +
> > counter value into the buffer on overflow, as in b[n] = H(b[n] + c
> > + i[n]) in the kernel
> >(can control w
On Thu, Sep 13, 2012 at 08:51:15PM +0100, Mark Murray wrote:
> David O'Brien writes: On Thu, Sep 13, 2012 at 08:00:19PM +0100, Mark Murray
> wrote:
> > Mark,
> > Can you add more about your reasoning why the low-grade entropy should be
> > input before the high-quality cached entropy?
>
> Sure!
>
On Fri, 14 Sep 2012, Ian Lepore wrote:
On Fri, 2012-09-14 at 13:38 +, Bjoern A. Zeeb wrote:
On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
Hi,
I have removed freebsd-rc for this part of the discussion as it's
unrelated.
..
I think the one thing left I might be able to contribute is a lit
On Fri, Sep 14, 2012 at 2:38 PM, Bjoern A. Zeeb wrote:
> 7) send all data to the kernel and hash (arch dependent?) it + counter value
>into the buffer on overflow, as in b[n] = H(b[n] + c + i[n]) in the
> kernel
>(can control when buffer full and only then take action when
>needed, ind
On Thu, 13 Sep 2012, Bjoern A. Zeeb wrote:
Hi,
I have removed freebsd-rc for this part of the discussion as it's
unrelated.
Ok, this is an aweful lot of individual parts and my feeling is that
we want to go through them very focused. Some of them have been
discussed enough already with good s
26 matches
Mail list logo
