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 nothing like RDRAND/RDSEED? Are
> > > they,
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 it.
I don't
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)
> or other VMs on the
> 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 gathering
> >
> > Your change _creates_
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 entirely. But they have to be
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 being counted
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 contributed. What wasn't
>
>> 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
one additional thing about the behaviour of vm.*{min,max}
is that they do not (currently?) consider how much memory
is consumed by major kernel consumers like pools. eg, there
is a known radeondrmkms leak we have not figured out why it
happens only sometimes, and this ends up making the kmem-160
> 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 may be known (by
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.
Indeed, I
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 create a long-lived
> > situation where the
> 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
42 matches
Mail list logo
