Re: random(4) changes

> 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

Re: random(4) changes

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

Re: random(4) changes

> 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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

> 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

Re: random(4) changes

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. > > > >

Re: random(4) changes

(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.

Re: random(4) changes

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

Re: random(4) changes

>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-crypto@vger.kernel.org, linux-ker...@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu Subject: Re: ra

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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:

Re: random(4) changes

> 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

Re: random(4) changes

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

Re: random(4) changes

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,

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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 >

Re: random(4) changes

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

Re: random(4) changes

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. > >

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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 > >

Re: random(4) changes

> > > 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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

Re: random(4) changes

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

random(4) changes

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