Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-30 Thread Pavel Machek
Hi! On Tue 2017-07-18 21:51:33, Theodore Ts'o wrote: > On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > > The only really good solution I know of is to find a way to provide a > > chunk of randomness early in the boot process. John Denker has a good > > discussion of doing this by

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-30 Thread Pavel Machek
Hi! On Tue 2017-07-18 21:51:33, Theodore Ts'o wrote: > On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > > The only really good solution I know of is to find a way to provide a > > chunk of randomness early in the boot process. John Denker has a good > > discussion of doing this by

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-23 Thread Theodore Ts'o
On Sun, Jul 23, 2017 at 02:05:38PM -0400, Sandy Harris wrote: > Sandy Harris wrote: > > > The biggest problem with random(4) is that you cannot generate good > > output without a good seed & just after boot, ... > > > > The only really good solution I know of is to find a

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-23 Thread Theodore Ts'o
On Sun, Jul 23, 2017 at 02:05:38PM -0400, Sandy Harris wrote: > Sandy Harris wrote: > > > The biggest problem with random(4) is that you cannot generate good > > output without a good seed & just after boot, ... > > > > The only really good solution I know of is to find a way to provide a > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-23 Thread Sandy Harris
Sandy Harris wrote: > The biggest problem with random(4) is that you cannot generate good > output without a good seed & just after boot, ... > > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. John

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-23 Thread Sandy Harris
Sandy Harris wrote: > The biggest problem with random(4) is that you cannot generate good > output without a good seed & just after boot, ... > > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. John Denker has a good >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Stephan Müller
Am Freitag, 21. Juli 2017, 17:09:11 CEST schrieb Arnd Bergmann: Hi Arnd, > On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: > >> Um, the timer is the largest number of interrupts on my system.

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Stephan Müller
Am Freitag, 21. Juli 2017, 17:09:11 CEST schrieb Arnd Bergmann: Hi Arnd, > On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: > >> Um, the timer is the largest number of interrupts on my system. Compare: > >>

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Arnd Bergmann
On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: >> Um, the timer is the largest number of interrupts on my system. Compare: >> >> CPU0 CPU1 CPU2 CPU3 >> LOC:6396552

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Arnd Bergmann
On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller wrote: > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: >> Um, the timer is the largest number of interrupts on my system. Compare: >> >> CPU0 CPU1 CPU2 CPU3 >> LOC:639655260388656558646

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Jeffrey Walton
Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Jeffrey Walton
Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Stephan Müller
Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: Hi Theodore, > On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > > I concur with your rationale where de-facto the correlation is effect is > > diminished and eliminated with the fast_pool and the minimal entropy > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-21 Thread Stephan Müller
Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: Hi Theodore, > On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > > I concur with your rationale where de-facto the correlation is effect is > > diminished and eliminated with the fast_pool and the minimal entropy > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-20 Thread Theodore Ts'o
On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > I concur with your rationale where de-facto the correlation is effect is > diminished and eliminated with the fast_pool and the minimal entropy > estimation of interrupts. > > But it does not address my concern. Maybe I was not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-20 Thread Theodore Ts'o
On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > I concur with your rationale where de-facto the correlation is effect is > diminished and eliminated with the fast_pool and the minimal entropy > estimation of interrupts. > > But it does not address my concern. Maybe I was not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-20 Thread Stephan Müller
Am Mittwoch, 19. Juli 2017, 19:26:03 CEST schrieb Theodore Ts'o: Hi Theodore, > On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > > In the email [1] I have expressed the core concerns I see -- none of them > > address the need to keep the Jitter RNG as one noise source. To

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-20 Thread Stephan Müller
Am Mittwoch, 19. Juli 2017, 19:26:03 CEST schrieb Theodore Ts'o: Hi Theodore, > On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > > In the email [1] I have expressed the core concerns I see -- none of them > > address the need to keep the Jitter RNG as one noise source. To

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Theodore Ts'o
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Theodore Ts'o
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Greg Kroah-Hartman
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: > > Hi Theodore, > > > > I've been trying to take the best features and suggestions from your > > proposal and integrating them into /dev/random already. Things

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Greg Kroah-Hartman
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: > > Hi Theodore, > > > > I've been trying to take the best features and suggestions from your > > proposal and integrating them into /dev/random already. Things

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Stephan Müller
Am Mittwoch, 19. Juli 2017, 03:51:33 CEST schrieb Theodore Ts'o: Hi Theodore, > If the real unpredictability is really coming from the interrupts > changing the state of the CPU microarchitecture, the real question is > how many interrupts do you need before you consider things > "unpredictable"

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Stephan Müller
Am Mittwoch, 19. Juli 2017, 03:51:33 CEST schrieb Theodore Ts'o: Hi Theodore, > If the real unpredictability is really coming from the interrupts > changing the state of the CPU microarchitecture, the real question is > how many interrupts do you need before you consider things > "unpredictable"

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: Hi Theodore, > > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. Things that > I've chosen not take is basically because I disbelieve that the Jitter >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-19 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: Hi Theodore, > > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. Things that > I've chosen not take is basically because I disbelieve that the Jitter >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Theodore Ts'o
On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. John Denker has a good > discussion of doing this by modifying the kernel image & Ted talks of > doing it via the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Theodore Ts'o
On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. John Denker has a good > discussion of doing this by modifying the kernel image & Ted talks of > doing it via the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Sandy Harris
On Tue, Jul 18, 2017 at 5:08 PM, Theodore Ts'o wrote: > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. A good approach. > Things that I've chosen not take is basically because I disbelieve > that the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Sandy Harris
On Tue, Jul 18, 2017 at 5:08 PM, Theodore Ts'o wrote: > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. A good approach. > Things that I've chosen not take is basically because I disbelieve > that the Jitter RNG is

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Theodore Ts'o
On Tue, Jul 18, 2017 at 04:37:11PM +0200, Stephan Müller wrote: > > > > > I have stated the core concerns I have with random.c in [1]. To remedy > > > these core concerns, major changes to random.c are needed. With the past > > > experience, I would doubt that I get the changes into random.c. > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Theodore Ts'o
On Tue, Jul 18, 2017 at 04:37:11PM +0200, Stephan Müller wrote: > > > > > I have stated the core concerns I have with random.c in [1]. To remedy > > > these core concerns, major changes to random.c are needed. With the past > > > experience, I would doubt that I get the changes into random.c. > >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:52:12 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > I have stated the core concerns I have with random.c in [1]. To remedy > > these core concerns, major changes to random.c are needed. With the past > > experience, I would doubt that I get the changes into

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:52:12 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > I have stated the core concerns I have with random.c in [1]. To remedy > > these core concerns, major changes to random.c are needed. With the past > > experience, I would doubt that I get the changes into

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 10:45:12AM +0200, Stephan Müller wrote: > Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: > > Hi Greg, > > > external references do not last as long as the kernel change log does :( > > What would be the best way to cite a 50+ page document? I got a

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: Hi Greg, > external references do not last as long as the kernel change log does :( What would be the best way to cite a 50+ page document? I got a suggestion to include the ASCII version of the document into Documentation/

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: Hi Greg, > external references do not last as long as the kernel change log does :( What would be the best way to cite a 50+ page document? I got a suggestion to include the ASCII version of the document into Documentation/

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 09:59:09AM +0200, Stephan Müller wrote: > The LRNG with the following properties: > > * noise source: interrupts timing with fast boot time seeding > > * lockless LFSR to collect raw entropy > > * use of standalone ChaCha20 based RNG with the option to use a >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Greg Kroah-Hartman
On Tue, Jul 18, 2017 at 09:59:09AM +0200, Stephan Müller wrote: > The LRNG with the following properties: > > * noise source: interrupts timing with fast boot time seeding > > * lockless LFSR to collect raw entropy > > * use of standalone ChaCha20 based RNG with the option to use a >

[RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * "atomic" seeding of secondary DRBG to

[RFC PATCH v12 3/4] Linux Random Number Generator

2017-07-18 Thread Stephan Müller
The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * "atomic" seeding of secondary DRBG to