> 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 d
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 ca
> 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 t
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 de
>> 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 "irrele
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 w
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. so
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 that
>From smuel...@chronox.de Fri Apr 29 04:56:49 2016
From: Stephan Mueller
To: George Spelvin
Cc: herb...@gondor.apana.org.au, linux-crypto@vger.kernel.org,
linux-ker...@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
>
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 entro
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 fla
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 that
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: http://gondor.apana.org.au/~herber
> 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 *doe
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 ear
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 yo
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 magic
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 entropy-st
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
> diffe
Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
Hi George,
>
> > not the rest of Stephan's input handling code: the parity
> > calculation and XORing the resulting single bit into the entropy pool.
>
> Indeed, this is an incredibly popular novice mistake and I don't
> understand why
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.
>
> S
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.
> https:/
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 that
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 as
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 every
I just discovered this huge conversation and am trying to read it all
and get caught up.
I know I should finish reading before I start writing, but too many ideas
are bubbling up.
> not the rest of Stephan's input handling code: the parity
> calculation and XORing the resulting single bit into t
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 not
> > > 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 rand
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 horrib
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 g
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 d
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 o
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 ro
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 propo
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 proble
40 matches
Mail list logo
