On Sun, Apr 04, 2021 at 11:02:02PM +, Taylor R Campbell wrote:
>
> Lots of SoCs have on-board RNGs these days; there are Intel and ARM
> CPU instructions (no ARMv8.5 hardware yet that I know of, but we're
> ready for its RNG!); some crypto decelerators like tpm(4), ubsec(4),
> and hifn(4)
On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
>
> > But what you're missing is that neither does what you
> > think. When rndctl -L runs after the system comes up multiuser, all
> > entropy samples that have been
At Wed, 7 Apr 2021 22:47:39 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> When you create a custom setup like that, you will have to replace
> etc/rc.d/entropy with a custom solution (e.g. mounting some flash storage).
No stor
On Wed, Apr 07, 2021 at 12:14:58PM -0700, Greg A. Woods wrote:
> > You run it once. Manually. And never again.
>
> Nope, sorry, that's not a good enough answer.
It is for the typical and default installs.
> It doesn't solve the
> problem of dealing with a lack of mutable storage.
When you
At Wed, 7 Apr 2021 09:52:29 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > > Isn't it as simple as:
> > >
> > > dd bs=32 if=/dev/urandom of=/
On Wed, Apr 07, 2021 at 07:53:07AM -0400, matthew sporleder wrote:
> So on a brand new installation/first boot why isn't the clock a
> sufficiently random thing? (anymore?)
Becaus it isn't random?
> Hung and unusable systems are a big problem. Happening on the first
> boot is not a good first
On Wed, Apr 7, 2021 at 7:10 AM Martin Husemann wrote:
>
> On Wed, Apr 07, 2021 at 07:05:12AM -0400, matthew sporleder wrote:
> > Is the issue gaw saw exclusive to xen first boots? Are there other
> > ways to end up in his situation?
>
> It happens on all new installations for machines with no
On Tue, 6 Apr 2021, RVP wrote:
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
On Wed, Apr 07, 2021 at 07:05:12AM -0400, matthew sporleder wrote:
> Is the issue gaw saw exclusive to xen first boots? Are there other
> ways to end up in his situation?
It happens on all new installations for machines with no RNG, which is
the far majority of everything but "newish" amd64 and
> On Apr 6, 2021, at 8:09 AM, Taylor R Campbell wrote:
>
>
>> 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
On Tue, Apr 06, 2021 at 06:24:38PM +, Koning, Paul wrote:
> > Isn't it as simple as:
> >
> > dd bs=32 if=/dev/urandom of=/dev/random
> >
> > ?
>
> That runs the risk of people thinking it adds entropy. I'd be more
> comfortable with this:
>
> dd bs=32 if=/dev/zero
On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > Isn't it as simple as:
> >
> > dd bs=32 if=/dev/urandom of=/dev/random
>
> No, that still leaves the question of _when_ to run it. (And, at least
> at the moment, where to put it. /etc/rc.local?)
Of course not!
You run it
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
> > in
> 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
>>
>> I
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
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
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
On Mon, Apr 05, 2021 at 02:13:31PM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> > &g
At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> >
> > BTW, to me reusing the same entropy on every reboot seems less secure.
>
On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
>
> BTW, to me reusing the same entropy on every reboot seems less secure.
Sure. But that's not what the code actually does.
Please, read the code in more depth (or in this case, breadth), then argue
about it.
At Mon, 5 Apr 2021 15:35:12 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> All those inputs are *already* being injected into the entropy pool. If you
> don't understand that, you need to read the code more.
I don't see how. I don'
On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > If I understood it properly, there's no need for
On Sun, Apr 04, 2021 at 01:08:20PM -0700, Greg A. Woods wrote:
>
> I trust the randomness and in-observability and isolation of the
> behaviour of my system's fans far more than I would trust Intel's RDRAND
> or RDSEED instructions.
I do not. However, I do differ with Taylor in that I believe
On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > If I understood it properly, there's no need for
At Mon, 5 Apr 2021 03:02:42 +0200, Joerg Sonnenberger wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Except that's not what the system is doing. It removes the seed file on
> boot and creates a new one on shutdown.
That's not exactly what the documentation say
At Mon, 5 Apr 2021 16:13:55 +1200, Lloyd Parkes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> The current implementation prints out a message whenever it blocks a
> process that wants randomness, which immediately makes this
> implementation superior t
At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If I understood it properly, there's no need for such a knob.
> echo 0123456789abcdef0123456789abcdef > /dev/random
>
> will get you back to the state
At Sun, 4 Apr 2021 18:47:23 -0700, Brian Buhrow wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Hello. As I understand it, Greg ran into this problem on a xen domu.
> In checking my NetBSD-9 system running as a domu under xen-4.14.1,
> there is no rdra
h...@netbsd.org (Havard Eidnes) writes:
>I also presented a workaround for this problem; if you are reasonably
>certain that you actually have mixed in a sufficient number of bits of
>sufficient quality into the randomness pool (see "rndctl -l -v"), you
>can do
Isn't that the same as before?
On Sun, Apr 04, 2021 at 06:47:23PM -0700, Brian Buhrow wrote:
> Hello. As I understand it, Greg ran into this problem on a xen domu. In
> checking my NetBSD-9
> system running as a domu under xen-4.14.1, there is no rdrand or rdseed
> feature exposed to
> domu's by xen. This observation is
On Mon, Apr 05, 2021 at 01:16:56AM +, RVP wrote:
> [...]
> Hmm. I have to say, that now I find myself not disagreeing with Greg's
> point of view: Maybe NetBSD's default is too strict and a knob like
> kern.entropy.use_pooh_poohed_sources=1 would not be a bad thing for
> some users--with all
h...@uninett.no (Havard Eidnes) writes:
>Well, if I'm not mistaken, the actual implementation was tested,
>not just a theoretical study of the design. And, as I said,
>thermal noise is one of the well-known physical systems which
>provide actual entropy.
That's probably why other sources of
On Apr 4, 23:09, Taylor R Campbell wrote:
}
} > Date: Sun, 04 Apr 2021 12:58:09 -0700
} > From: "Greg A. Woods"
} > References:
} > <20210404094958.692f360...@jupiter.mumble.net>
} >
} > At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
} > >
} > > Your change _creates_ the lie
On Mon, Apr 05, 2021 at 12:51:44AM +0200, Joerg Sonnenberger wrote:
> On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > Perhaps sysinst(8) should ask
> >
> > Do you need a hyper-secure system?
> >
> > If yes, then leave things as they are today. But if you answer no,
> > we
On Sun, 4 Apr 2021, Taylor R Campbell wrote:
No, because the output of /dev/random and /dev/urandom is the output
of a pseudorandom number generator that meets modern standards of
security.
If anyone had _ever_ published statistical tests that the PRNG failed
in a detectable way, then (a) this
With some trepidation, I'm going to dip into this conversation even
though I haven't read all of. I don't have the mental fortitude for
that. I have two suggestions, one short and one long.
Firstly, we could just have an rc.d script that checks to see if the
system has /var/db/entropy-file
Date:Mon, 5 Apr 2021 01:14:01 +0200
From:Joerg Sonnenberger
Message-ID:
| That is discussed in the security model Taylor presented a long time
| ago. In short: nothing. In most use cases, you are screwed at this point
| anyway
This is where the disconnect is
> All that changed is that we don't pretend it provides entropy.
Instead, you pretend it provides none.
Neither pretense is accurate (where the "pretend it provides entropy"
refers to providing any non-configurable fixed amount). The real
problem here, as I see it, is that NetBSD qua NetBSD
Hello. As I understand it, Greg ran into this problem on a xen domu. In
checking my NetBSD-9
system running as a domu under xen-4.14.1, there is no rdrand or rdseed feature
exposed to
domu's by xen. This observation is confirmed by looking at the xen command
line reference
page:
On Sun, Apr 04, 2021 at 11:47:10PM +0700, Robert Elz wrote:
> If not, what prevents someone from reading (copying) the file from the
> system while it is stopped (assessing the storage device via other methods)
> and then knowing exactly what the seed is going to be when the system boots?
That is
On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > > What about architectures that have no
On Sun, 4 Apr 2021, Greg A. Woods wrote:
At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
Your change _creates_ the lie that every bit of data entered this way
is drawn from a source with independent uniform distribution.
No, my change _allows_ the administrator to decide which
On Mon, Apr 05, 2021 at 12:07:49AM +0200, Havard Eidnes wrote:
> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.
It's not without foundation. Remember the first hardware RNG on x86?
>> Nope, not entirely. But they have to be seeded once. If they have
>> storage which survives reboots, and entropy is saved and restored on
>> reboot, they will be ~fine.
> BTW, to me reusing the same entropy on every reboot seems less
> secure.
Hence the "saved and" part of the above. (I
> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.
I don't doubt the ability. I don't doubt that they _can_.
I question whether they _do_. (And, indeed, there has been at least
one
On Sun, Apr 4, 2021 at 7:14 PM Havard Eidnes wrote:
> Well. That depends on what you mean by "entropy".
Hit the nail on the head.
Although there is only one definition of entropy in information theory
/ cryptography, it has different colloquial meanings, especially on
the web. It makes
At Sun, 4 Apr 2021 23:09:18 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If you know this (and this is something I certainly can't confidently
> assert!), you can write 32 bytes to /dev/random, save a seed, and be
> done with
At Mon, 5 Apr 2021 01:05:58 +0200, Joerg Sonnenberger wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Part of the problem here is that most of the non-RNG data sources are
> easily observable either from the local system (e.g. any malicious user)
>
> Date: Sun, 4 Apr 2021 21:24:56 + (UTC)
> From: RVP
>
> I think running the /dev/random bit-stream through some statistical
> tests, (both on RDRAND/RDSEED-based and estimator-based as in your
> patch) would be useful here.
No, because the output of /dev/random and /dev/urandom is the
>> > No amount of uptime and activity was increasing the entropy in my
>> > system before I patched it.
>>
>> As I understand it, entropy was being contributed. What wasn't
>> happening was the random driver code recognizing and acknowledging that
>> entropy, because it had no way to tell how
> Date: Sun, 04 Apr 2021 12:58:09 -0700
> From: "Greg A. Woods"
> References:
> <20210404094958.692f360...@jupiter.mumble.net>
>
> At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
> wrote:
> Subject: Re: regarding the changes to kernel entropy
On Sun, Apr 04, 2021 at 09:24:56PM +, RVP wrote:
> PS. Is there a way to get the bit-stream from the various in-kernel
> sources so that we can run them through these sort of tests? That
> way we can check--not intuit--how random the bit-streams they
> produce really are.
Part of the problem
> Date: Sun, 4 Apr 2021 11:14:31 -0700
> From: John Nemeth
>
> I understand the need for good random sources, and won't argue
> it. My question is, how can we tell what random sources a system
> actually has, i.e. is there some flag that cpuctl identify shows
> when a system has
> Date: Sun, 04 Apr 2021 23:47:10 +0700
> From: Robert Elz
>
> Date:Sun, 4 Apr 2021 15:28:13 +
> From:Taylor R Campbell
> Message-ID: <20210404152814.3c56360...@jupiter.mumble.net>
>
> | you can let NetBSD take care of it automatically
> | on subsequent
On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > Personally, I'm happy with anything that your average high school
> > student is unlikely to be able to crack in an hour. I don't run
> > a bank, or a military installation, and I'm not the NSA. If someone
> > is prepared to put
At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > What about architectures that have nothing like RDRAND/RDSEED? Are
> > they, effectively, totally unsupported now?
>
> Nope, not ent
At Mon, 05 Apr 2021 00:07:49 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Indeed, that's also compatible with what I wrote. The samples
> from whatever sources you have are still being mixed into the
> pool, but they are not b
At Sun, 4 Apr 2021 16:39:11 -0400 (EDT), Mouse
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > No amount of uptime and activity was increasing the entropy in my
> > system before I patched it.
>
> As I understand it, entropy was being cont
>> My question is, how can we tell what random sources a system actually
>> has, i.e. is there some flag that cpuctl identify shows when a system
>> has RDRAND/RDSEED?
>
> What about architectures that have nothing like RDRAND/RDSEED? Are
> they, effectively, totally unsupported now?
Nope, not
>> Do note, the existing randomness sources are still being sampled and
>> mixed into the pool, so even if the starting state from the saved
>> entropy may be known (by violating the security of the storage),
>> it's still not possible to predict the complete stream of randomness
>> data once the
Personally, I'm happy with anything that your average high school
student is unlikely to be able to crack in an hour. I don't run
a bank, or a military installation, and I'm not the NSA. If someone
is prepared to put in the effort required to break into my systems,
then let them, it isn't
> No amount of uptime and activity was increasing the entropy in my
> system before I patched it.
As I understand it, entropy was being contributed. What wasn't
happening was the random driver code recognizing and acknowledging that
entropy, because it had no way to tell how much of it there
> My question is, how can we tell what random sources a system actually
> has, i.e. is there some flag that cpuctl identify shows when a system
> has RDRAND/RDSEED?
What about architectures that have nothing like RDRAND/RDSEED? Are
they, effectively, totally unsupported now?
/~\ The ASCII
At Sun, 04 Apr 2021 21:14:31 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Do note, the existing randomness sources are still being sampled and
> mixed into the pool, so even if the starting state from the saved
> entropy
At Sun, 04 Apr 2021 23:47:10 +0700, Robert Elz wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If we want really good security, I'd submit we need to disable
> the random seed file, and RDRAND (and anything similar) until we
> have proof that they're perfect
At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > Date: Sat, 03 Apr 2021 12:24:29 -0700
> > From: "Greg A. Woods"
> >
> > Updating a system, even on -current, shouldn't cr
> Is that file encrypted?
As I understand it, no.
> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that. Regardless of
> how unproven that method might be.
Do note, the existing randomness sources are still
On Sun, Apr 04, 2021 at 11:14:31AM -0700, John Nemeth wrote:
> I understand the need for good random sources, and won't argue
> it. My question is, how can we tell what random sources a system
> actually has, i.e. is there some flag that cpuctl identify shows
> when a system has
On Sun, Apr 04, 2021 at 11:14:31AM -0700, John Nemeth wrote:
> I understand the need for good random sources, and won't argue
> it. My question is, how can we tell what random sources a system
> actually has, i.e. is there some flag that cpuctl identify shows
> when a system has
On Apr 4, 9:49, Taylor R Campbell wrote:
}
} What NetBSD-current is telling you on your Xen system, on a CPU
} predating RDRAND/RDSEED, is the unfortunate truth that there is no
} reliable source of entropy available in your system -- annoying, yes,
} but when you talk about `matters so
Date:Sun, 4 Apr 2021 15:28:13 +
From:Taylor R Campbell
Message-ID: <20210404152814.3c56360...@jupiter.mumble.net>
| you can let NetBSD take care of it automatically
| on subsequent boots by running `/etc/rc.d/random_seed stop' to save a
| seed to disk.)
Is
> Date: Sun, 4 Apr 2021 10:40:22 -0400 (EDT)
> From: Mouse
>
> > What NetBSD-current is telling you on your Xen system, on a CPU
> > predating RDRAND/RDSEED, is the unfortunate truth that there is no
> > reliable source of entropy available in your system --
>
> Not quite. That there is
> What NetBSD-current is telling you on your Xen system, on a CPU
> predating RDRAND/RDSEED, is the unfortunate truth that there is no
> reliable source of entropy available in your system --
Not quite. That there is nothing which NetBSD, independent of the
sysadmin, is confident is a reliable
I have updated the rndctl(8) documentation so it reflects the current
model in the kernel and is no longer misleading.
It could still use some extra work (e.g. -l could print number of
samples collected).
On Sat, Apr 03, 2021 at 10:03:21PM +0200, Steffen Nurpmeso wrote:
> Btw i track
>
>
> Date: Sat, 03 Apr 2021 12:24:29 -0700
> From: "Greg A. Woods"
>
> Updating a system, even on -current, shouldn't create a long-lived
> situation where the system documentation and the behaviour and actions
> of system commands is completely out of sync with the behaviour of the
> kernel, and
Btw i track
https://github.com/smuellerDD/jitterentropy-library.git
for about two years, and i "never" (which is a couple of years at
least) understood why something like this isn't simply used.
For example in the myriads of times the scheduler runs each
second, a little bit of that can be
84 matches
Mail list logo
