On Tue, 6 Apr 2021, Taylor R Campbell wrote:
Why do you say that? We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.
Is the output of /dev/random also
At Tue, 6 Apr 2021 20:21:43 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> >
> > And the stock implementation has no possibility of ever providing an
> > initial seed at all on its
> On Apr 6, 2021, at 2:21 PM, Martin Husemann wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
>> Except it seems to be useless in practice without an initial seed,
>
> Yes.
>
>> And the stock implementation has no possibility of ever
> On Apr 6, 2021, at 1:54 PM, Greg A. Woods wrote:
>
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
>>
>>> dd if=/dev/urandom of=/dev/random bs=32 count=1
>>
>> It's no better.
>
> So then I would say
On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> Except it seems to be useless in practice without an initial seed,
Yes.
> And the stock implementation has no possibility of ever providing an
> initial seed at all on its own (unlike previous implementations, and of
> course
At Tue, 6 Apr 2021 12:08:54 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> The main issue that hits people is that the traditional mechanism by
> which the OS reports a potential security problem with entropy is for
> it to make applications
At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > dd if=/dev/urandom of=/dev/random bs=32 count=1
>
> It's no better.
So then I would say that in fact using some less trustworthy source of
randomness (e.g.
On Thu, Apr 01, 2021 at 11:47:22PM +0530, Piyush Sachdeva wrote:
> To whomever it may concern,
> Please find attached the proposal for the project of extending the standard
> posix_spawn(3) to support chdir(2) in NetBSD. This is just a draft and I
> would like to hear from you, about all the
Thanks - that is useful information.
I think the big point is that the new seed file is generated from
urandom, not from the internal state, so the new seed doesn't leaak
internal state. The "save entropy" language didn't allow me to conclude
that.
Also, your explanation is about updating, but
> Date: Tue, 06 Apr 2021 07:55:54 -0400
> From: Greg Troxel
>
> Thor Lancelot Simon writes:
>
> > shuts down, again all entropy samples that have been added (which, again,
> > are accumulating in the per-cpu pools) are propagated to the global pool;
> > all the stream RNGs rekey themselves
> Date: Mon, 05 Apr 2021 10:58:58 +0700
> From: Robert Elz
>
> I understand that some people desire highly secure systems (I'm not
> convinced that anyone running NetBSD can really justify that desire,
> but that's beside the point) and that's fine - make the system be able
> to be as secure as
> Date: Mon, 5 Apr 2021 01:16:56 + (UTC)
> From: RVP
>
> Then, the issue here is one of predictability. NetBSD doesn't want,
> for extremely valid reason, to incorporate any perturbation sources
> which have been pooh-poohed in the technical literature.
Why do you say that? We do
Thor Lancelot Simon writes:
> shuts down, again all entropy samples that have been added (which, again,
> are accumulating in the per-cpu pools) are propagated to the global pool;
> all the stream RNGs rekey themselves again; then the seed is extracted.
It seems obvious to me that "extracting"
On Mon, Apr 05, 2021 at 01:22:49PM -0700, Greg A. Woods wrote:
> I don't see how. I don't see any evidence for that happening.
>
> So, show me how entropy is being collected in my system:
>
> 16:18 [1.793] # uptime
> 4:19PM up 22 days, 16:04, 2 users, load averages: 0.00, 0.00, 0.00
> 16:19
14 matches
Mail list logo
