> I think we can agree that we disagree.
Yes, we agree on that, at least!
The problem is, this is supposed to be a matter of fact, not opinion,
so there should be one right answer.
I suppose it's possible it's still an issue of terminology, but we've
exhausted
> Though, I will get back to the
> I think we can agree that we disagree.
Yes, we agree on that, at least!
The problem is, this is supposed to be a matter of fact, not opinion,
so there should be one right answer.
I suppose it's possible it's still an issue of terminology, but we've
exhausted
> Though, I will get back to the
Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin:
Hi George,
> > What I am saying that the bits in one given time stamp are mutually
> > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that
> > very same time stamp.
>
> And I'm saying that's wrong.
I think we
Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin:
Hi George,
> > What I am saying that the bits in one given time stamp are mutually
> > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that
> > very same time stamp.
>
> And I'm saying that's wrong.
I think we
> What I am saying that the bits in one given time stamp are mutually
> independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that
> very same time stamp.
And I'm saying that's wrong.
We are interested in the correlation from the point of view of someone
who knows all previous
> What I am saying that the bits in one given time stamp are mutually
> independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that
> very same time stamp.
And I'm saying that's wrong.
We are interested in the correlation from the point of view of someone
who knows all previous
Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin:
Hi George,
> >> 1. It DOES depend on the attacker. Any statement about independence
> >>
> >>depends on the available knowledge.
> >>
> >> 2. XOR being entropy preserving depends on independence ONLY, it does
> >>
> >>NOT
Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin:
Hi George,
> >> 1. It DOES depend on the attacker. Any statement about independence
> >>
> >>depends on the available knowledge.
> >>
> >> 2. XOR being entropy preserving depends on independence ONLY, it does
> >>
> >>NOT
>> 1. It DOES depend on the attacker. Any statement about independence
>>depends on the available knowledge.
>> 2. XOR being entropy preserving depends on independence ONLY, it does
>>NOT depend on identical distribution. The latter is a red herring.
>>(An English metaphor for
>> 1. It DOES depend on the attacker. Any statement about independence
>>depends on the available knowledge.
>> 2. XOR being entropy preserving depends on independence ONLY, it does
>>NOT depend on identical distribution. The latter is a red herring.
>>(An English metaphor for
Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin:
Hi George,
> > I think there is a slight mixup: IID is not related to an attacker
> > predicting things. IID is simply a statistical measure, it is either there
> > or not. It does not depend on an attacker (assuming that the attacker
Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin:
Hi George,
> > I think there is a slight mixup: IID is not related to an attacker
> > predicting things. IID is simply a statistical measure, it is either there
> > or not. It does not depend on an attacker (assuming that the attacker
> I think there is a slight mixup: IID is not related to an attacker
> predicting things. IID is simply a statistical measure, it is either there
> or not. It does not depend on an attacker (assuming that the attacker
> cannot change the data). Note, the IID is only needed to claim that the
> XOR
> I think there is a slight mixup: IID is not related to an attacker
> predicting things. IID is simply a statistical measure, it is either there
> or not. It does not depend on an attacker (assuming that the attacker
> cannot change the data). Note, the IID is only needed to claim that the
> XOR
Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin:
Hi George,
> (Note that we have two chains of e-mails crossing mid-stream. I'm in
> the middle of working on a much longer reply to your previous e-mail.)
>
> >> They're not independent, nor are they identically distributed.
> >
> >
Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin:
Hi George,
> (Note that we have two chains of e-mails crossing mid-stream. I'm in
> the middle of working on a much longer reply to your previous e-mail.)
>
> >> They're not independent, nor are they identically distributed.
> >
> >
(Note that we have two chains of e-mails crossing mid-stream. I'm in
the middle of working on a much longer reply to your previous e-mail.)
>> They're not independent, nor are they identically distributed.
> That is an interesting statement: you say that the time stamp has holes
> in it, i.e.
(Note that we have two chains of e-mails crossing mid-stream. I'm in
the middle of working on a much longer reply to your previous e-mail.)
>> They're not independent, nor are they identically distributed.
> That is an interesting statement: you say that the time stamp has holes
> in it, i.e.
Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin:
Hi George,
> > 1. the individual bits of a given 32 bit time stamp are independent
> >
> >(or IID in terms of NIST)
>
> They're not independent, nor are they identically distributed.
That is an interesting statement: you say
Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin:
Hi George,
> > 1. the individual bits of a given 32 bit time stamp are independent
> >
> >(or IID in terms of NIST)
>
> They're not independent, nor are they identically distributed.
That is an interesting statement: you say
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016
From: Stephan Mueller <smuel...@chronox.de>
To: George Spelvin <li...@horizon.com>
Cc: herb...@gondor.apana.org.au, linux-cry...@vger.kernel.org,
linux-kernel@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu
Subject: Re: ra
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016
From: Stephan Mueller
To: George Spelvin
Cc: herb...@gondor.apana.org.au, linux-cry...@vger.kernel.org,
linux-kernel@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu
Subject: Re: random(4) changes
Date: Thu, 28 Apr 2016 22:15:17 +0
Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin:
Hi George,
> > And considering that I only want to have 0.9 bits of entropy, why
> > should I not collapse it? The XOR operation does not destroy the existing
> > entropy, it only caps it to at most one bit of information theoretical
Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin:
Hi George,
> > And considering that I only want to have 0.9 bits of entropy, why
> > should I not collapse it? The XOR operation does not destroy the existing
> > entropy, it only caps it to at most one bit of information theoretical
I'd like to apologise for the harsh tone of my earlier message.
I was frustrated, and it showed.
I hope I can be more gentle as I continue to elaborate on the shortcomings
of that scheme.
Concentrating entropy is hard. To paraphrase Princess Leia, "the more
you tighten your grip, the more
I'd like to apologise for the harsh tone of my earlier message.
I was frustrated, and it showed.
I hope I can be more gentle as I continue to elaborate on the shortcomings
of that scheme.
Concentrating entropy is hard. To paraphrase Princess Leia, "the more
you tighten your grip, the more
Andi Kleen wrote:
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I came up with some very pretty code to fix this, which
tried to copy_to_user with a lock held.
After all my attempts to fix that fatal
Andi Kleen wrote:
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I came up with some very pretty code to fix this, which
tried to copy_to_user with a lock held.
After all my attempts to fix that fatal
Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:
Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > >
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> >
> > That would imply
Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:
Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > >
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> >
> > That would imply
On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote:
>
> I posted patches to fix this. At some point it definitely has to be.
Can you point me to the patch submission?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote:
>
> I posted patches to fix this. At some point it definitely has to be.
Can you point me to the patch submission?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
> And considering that I only want to have 0.9 bits of entropy, why
> should I not collapse it? The XOR operation does not destroy the existing
> entropy, it only caps it to at most one bit of information theoretical
> entropy.
No. Absolutely, demonstrably false.
The XOR operation certainly
> And considering that I only want to have 0.9 bits of entropy, why
> should I not collapse it? The XOR operation does not destroy the existing
> entropy, it only caps it to at most one bit of information theoretical
> entropy.
No. Absolutely, demonstrably false.
The XOR operation certainly
Am Dienstag, 26. April 2016, 16:43:30 schrieb George Spelvin:
Hi George,
(I am not covering the initial part as I leave you time to read through the
paper which should cover those aspects)
>
> That's what I don't like about Intel's RDRAND and similar hardware RNGs:
> they are whitening too
Am Dienstag, 26. April 2016, 16:43:30 schrieb George Spelvin:
Hi George,
(I am not covering the initial part as I leave you time to read through the
paper which should cover those aspects)
>
> That's what I don't like about Intel's RDRAND and similar hardware RNGs:
> they are whitening too
On Tue, Apr 26, 2016 at 07:04:15PM +0800, Herbert Xu wrote:
> Theodore Ts'o wrote:
> >
> > Yet another difference which I've noticed as I've been going over the
> > patches is that that since it relies on CRYPTO_DRBG, it drags in a
> > fairly large portion of the crypto subsystem,
On Tue, Apr 26, 2016 at 07:04:15PM +0800, Herbert Xu wrote:
> Theodore Ts'o wrote:
> >
> > Yet another difference which I've noticed as I've been going over the
> > patches is that that since it relies on CRYPTO_DRBG, it drags in a
> > fairly large portion of the crypto subsystem, and requires it
Schrieb Stephan Mueller:
> Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
>> Indeed, this is an incredibly popular novice mistake and I don't
>> understand why people keep making it.
> Can you please elaborate on your statement to help me understanding the issue
> and substantiate
Schrieb Stephan Mueller:
> Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
>> Indeed, this is an incredibly popular novice mistake and I don't
>> understand why people keep making it.
> Can you please elaborate on your statement to help me understanding the issue
> and substantiate
Hi!
> > > > When dropping the add_disk_randomness function in the legacy
> > > > /dev/random, I
> > > > would assume that without changes to add_input_randomness and
> > > > add_interrupt_randomness, we become even more entropy-starved.
> > >
> > > Sure, but your system isn't doing anything
Hi!
> > > > When dropping the add_disk_randomness function in the legacy
> > > > /dev/random, I
> > > > would assume that without changes to add_input_randomness and
> > > > add_interrupt_randomness, we become even more entropy-starved.
> > >
> > > Sure, but your system isn't doing anything
Am Dienstag, 26. April 2016, 20:44:39 schrieb Pavel Machek:
Hi Pavel,
> Hi1
>
> > > When dropping the add_disk_randomness function in the legacy
> > > /dev/random, I
> > > would assume that without changes to add_input_randomness and
> > > add_interrupt_randomness, we become even more
Am Dienstag, 26. April 2016, 20:44:39 schrieb Pavel Machek:
Hi Pavel,
> Hi1
>
> > > When dropping the add_disk_randomness function in the legacy
> > > /dev/random, I
> > > would assume that without changes to add_input_randomness and
> > > add_interrupt_randomness, we become even more
Hi1
> > When dropping the add_disk_randomness function in the legacy /dev/random, I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
> Sure, but your system isn't doing anything magical here. The main
>
Hi1
> > When dropping the add_disk_randomness function in the legacy /dev/random, I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
> Sure, but your system isn't doing anything magical here. The main
>
Am Montag, 25. April 2016, 23:07:35 schrieb Theodore Ts'o:
Hi Theodore,
>
> > When dropping the add_disk_randomness function in the legacy /dev/random,
> > I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
>
Am Montag, 25. April 2016, 23:07:35 schrieb Theodore Ts'o:
Hi Theodore,
>
> > When dropping the add_disk_randomness function in the legacy /dev/random,
> > I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
>
On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I did not write that. I think
On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I did not write that. I think Andi is quoting himself here, not me.
>
Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:
Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > >
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> >
> > That would imply
Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:
Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > >
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> >
> > That would imply
Theodore Ts'o wrote:
>
> Yet another difference which I've noticed as I've been going over the
> patches is that that since it relies on CRYPTO_DRBG, it drags in a
> fairly large portion of the crypto subsystem, and requires it to be
> compiled into the kernel (instead of being
Theodore Ts'o wrote:
>
> Yet another difference which I've noticed as I've been going over the
> patches is that that since it relies on CRYPTO_DRBG, it drags in a
> fairly large portion of the crypto subsystem, and requires it to be
> compiled into the kernel (instead of being loaded as needed
On Sun, Apr 24, 2016 at 10:03:45AM +0200, Stephan Mueller wrote:
>
> I agree here. The only challenge with the current implementation is the time
> the fast_pool is to be mixed into an entropy pool. This requires a lock and
> quite some code afterwards.
This only happens no more than once
On Sun, Apr 24, 2016 at 10:03:45AM +0200, Stephan Mueller wrote:
>
> I agree here. The only challenge with the current implementation is the time
> the fast_pool is to be mixed into an entropy pool. This requires a lock and
> quite some code afterwards.
This only happens no more than once
On Mon, Apr 25, 2016 at 09:06:03AM -0700, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
>
>
On Mon, Apr 25, 2016 at 09:06:03AM -0700, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
>
> Ignoring problems does
> > > If it is the latter, can you explain where the scalability issue comes in?
> >
> > A single pool which is locked/written to does not scale. Larger systems
> > need multiple pools
>
> That would imply that even when you have a system with 1000 CPUs, you want to
> have a large amount of
> > > If it is the latter, can you explain where the scalability issue comes in?
> >
> > A single pool which is locked/written to does not scale. Larger systems
> > need multiple pools
>
> That would imply that even when you have a system with 1000 CPUs, you want to
> have a large amount of
Am Montag, 25. April 2016, 10:38:25 schrieb Andi Kleen:
Hi Andi,
> On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> > Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
> >
> > Hi Andi,
> >
> > > Sandy Harris writes:
> > >
> > > There is also
Am Montag, 25. April 2016, 10:38:25 schrieb Andi Kleen:
Hi Andi,
> On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> > Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
> >
> > Hi Andi,
> >
> > > Sandy Harris writes:
> > >
> > > There is also the third problem of
On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
>
> Hi Andi,
>
> > Sandy Harris writes:
> >
> > There is also the third problem of horrible scalability of /dev/random
> > output on larger
On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
>
> Hi Andi,
>
> > Sandy Harris writes:
> >
> > There is also the third problem of horrible scalability of /dev/random
> > output on larger systems, for which patches are
Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
Hi Andi,
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
Hi Andi,
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
>
> Ignoring problems
Sandy Harris writes:
There is also the third problem of horrible scalability of /dev/random
output on larger systems, for which patches are getting ignored.
https://lkml.org/lkml/2016/2/10/716
Ignoring problems does not make them go away.
-Andi
--
a...@linux.intel.com
Sandy Harris writes:
There is also the third problem of horrible scalability of /dev/random
output on larger systems, for which patches are getting ignored.
https://lkml.org/lkml/2016/2/10/716
Ignoring problems does not make them go away.
-Andi
--
a...@linux.intel.com -- Speaking for myself
Am Samstag, 23. April 2016, 22:03:23 schrieb Theodore Ts'o:
Hi Theodore,
> On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote:
> > I really like Stephan's idea of simplifying the interrupt handling,
> > replacing the multiple entropy-gathering calls in the current driver
> > with one
Am Samstag, 23. April 2016, 22:03:23 schrieb Theodore Ts'o:
Hi Theodore,
> On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote:
> > I really like Stephan's idea of simplifying the interrupt handling,
> > replacing the multiple entropy-gathering calls in the current driver
> > with one
On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote:
>
> I really like Stephan's idea of simplifying the interrupt handling,
> replacing the multiple entropy-gathering calls in the current driver
> with one routine called for all interrupts. See section 1.2 of his
> doc. That seems to me
On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote:
>
> I really like Stephan's idea of simplifying the interrupt handling,
> replacing the multiple entropy-gathering calls in the current driver
> with one routine called for all interrupts. See section 1.2 of his
> doc. That seems to me
Am Freitag, 22. April 2016, 18:27:48 schrieb Sandy Harris:
Hi Sandy,
> Stephan has recently proposed some extensive changes to this driver,
> and I proposed a quite different set earlier. My set can be found at:
> https://github.com/sandy-harris
>
> This post tries to find the bits of both
Am Freitag, 22. April 2016, 18:27:48 schrieb Sandy Harris:
Hi Sandy,
> Stephan has recently proposed some extensive changes to this driver,
> and I proposed a quite different set earlier. My set can be found at:
> https://github.com/sandy-harris
>
> This post tries to find the bits of both
Stephan has recently proposed some extensive changes to this driver,
and I proposed a quite different set earlier. My set can be found at:
https://github.com/sandy-harris
This post tries to find the bits of both proposals that seem clearly
worth doing and entail neither large implementation
Stephan has recently proposed some extensive changes to this driver,
and I proposed a quite different set earlier. My set can be found at:
https://github.com/sandy-harris
This post tries to find the bits of both proposals that seem clearly
worth doing and entail neither large implementation
76 matches
Mail list logo