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 m
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
> > chu
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
> discuss
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:
> >>
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
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
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
> >
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 cl
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 address
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 tru
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 that
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"
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
>
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 bo
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 v
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.
> >
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 rando
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
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
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/ -
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
> different
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 ensure
22 matches
Mail list logo