On 23.05.2020 02:38, Kamil Rytarowski wrote:
> On 01.05.2020 21:19, Taylor R Campbell wrote:
>> I propose that we additionally adopt getrandom and getentropy, two C
>> APIs the world is converging on.
>
> I propose to import the getrandom code with the Linux semantics and
> integrate into compat_l
On 23.05.2020 02:38, Kamil Rytarowski wrote:
> On 01.05.2020 21:19, Taylor R Campbell wrote:
>> I propose that we additionally adopt getrandom and getentropy, two C
>> APIs the world is converging on.
>
> I propose to import the getrandom code with the Linux semantics and
> integrate into compat_l
On 01.05.2020 21:19, Taylor R Campbell wrote:
> I propose that we additionally adopt getrandom and getentropy
I propose to import the getrandom code with the Linux semantics and
integrate into compat_linux(8). More and more software expects that in
place.
For the native (NetBSD) ABI, getentropy()
I have one more argument for making getentropy() block that hasn't
been made yet even though it may be the most basic: the name.
That is, I think users will reasonably expect that the data returned
by a function called "getentropy" will actually be "entropy" as
defined by the operating system in c
On Thu, May 14, 2020 at 08:11:32PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> > > Joerg Sonnenberger wrote:
> > > > > > > There's nothing wrong with the general idea of entropy estimation
> > > > > > > as
>
Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> > Joerg Sonnenberger wrote:
> > > > > > There's nothing wrong with the general idea of entropy estimation as
> > > > > > implemented in NetBSD-current. If you run -current on your
> > > > > > hypothe
On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > > > There's nothing wrong with the general idea of entropy estimation as
> > > > > implemented in NetBSD-current. If you run -current on your
> > > > > hypothetical
> > > > > emulator, it will ca
Joerg Sonnenberger wrote:
> > > > There's nothing wrong with the general idea of entropy estimation as
> > > > implemented in NetBSD-current. If you run -current on your hypothetical
> > > > emulator, it will calculate an entropy estimate of zero, and
> > > > /dev/random will block, as it should.
On Thu, May 14, 2020 at 03:12:13PM +0200, Joerg Sonnenberger wrote:
> I'd strongly argue that the only category where it really matters
> potentially are long term key generators. I would at the same time
> consider creating the ssh host keys as part of sysinst, but that's
> already setting up the
On Thu, May 14, 2020 at 10:35:48AM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > There's nothing wrong with the general idea of entropy estimation as
> > > implemented in NetBSD-current. If you run -current on your hypothetical
> > > emulator, it will calculate an entropy esti
Joerg Sonnenberger wrote:
> > There's nothing wrong with the general idea of entropy estimation as
> > implemented in NetBSD-current. If you run -current on your hypothetical
> > emulator, it will calculate an entropy estimate of zero, and
> > /dev/random will block, as it should. The question we
On Wed, May 13, 2020 at 12:19:06PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> > > I don't particularly care if we require 100 or 384 bits of estimated
> > > entropy, nor do I particularly care if the entropy
Joerg Sonnenberger wrote:
> On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> > I don't particularly care if we require 100 or 384 bits of estimated
> > entropy, nor do I particularly care if the entropy estimate of a
> > keystroke timestamp is 0 or 1 bit. But I do very much ca
On Tue, May 12, 2020 at 11:18:02AM -0400, Terry Moore wrote:
> A useful definition requires that third-party code will not have surprising
> security defects compared to their operation on other operating systems.
There are other concerns for whether third party code works well..
I'll just copy w
On Tue, May 12, 2020 at 12:37:57PM +, nia wrote:
> These use arandom exclusively on NetBSD:
> - gnutls (via nettle _rnd_get_system_entropy)
> Prefers getentropy and only uses getrandom if there's no getentropy.
> - openssl (syscall_random)
> Prefers getentropy and only uses getrandom if the
jo...@bec.de (Joerg Sonnenberger) writes:
>Please think what that statement means. Consider for fun emulating a 20
>year old computer with a deterministic high precision model keeping all
>storage in memory. There is no source of entropy in such a system and no
>way for the emulation to tell.
Sad
Andress Gustaffson wrote
> But I do very much care that if I
> accidentally try to generate an ssh key on a system that has no
> entropy at all, it must not succeed.
This above example is a question about ssh, not about the APIs getrandom()
or getentropy().
A kernel API cannot solve requirements
On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> I don't particularly care if we require 100 or 384 bits of estimated
> entropy, nor do I particularly care if the entropy estimate of a
> keystroke timestamp is 0 or 1 bit. But I do very much care that if I
> accidentally try to
nia wrote:
> I disagree that measuring "full entropy" is something that's possible
> to do in a sane, fair, or uncontroversial way.
Advocating the use of /dev/urandom and its equivalents on that basis
basically boils down to "because we can't agree on what level of
security we should require or ho
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> This unfortunate situation should be addressed by providing more
> entropy sources, not by burying our heads in the sand and pretending
> we have entropy when we don't. Adding more sources could mean
> reintroducing some timing
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> we have entropy when we don't. Adding more sources could mean
> reintroducing some timing based sources after careful analysis, but
> also things like having the installer install an initial random seed
> on the target machine (
nia wrote:
> > For the OpenBSD strategy to work, the system needs to actually refuse
> > to run if the seed can't be loaded (or full entropy achieved in some
> > other way). NetBSD doesn't do that. As long as there is any way
> > userland can start before full entropy has been achieved, all APIs
> Date: Mon, 11 May 2020 12:42:13 -0700 (PDT)
> From: Paul Goyette
>
> Why can't we allow the user to configure/enable estimation on a
> per-source basis? The default can certainly be "disabled", but
> why not override? Just like any other super-user thing, there's
> no reason not to enable sho
> Date: Mon, 11 May 2020 17:56:41 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> riastr...@netbsd.org (Taylor R Campbell) writes:
>
> >> Date: Mon, 11 May 2020 16:16:12 - (UTC)
> >> From: mlel...@serpens.de (Michael van Elst)
> >>
> >> Now we put all trust in loading a constan
On Mon, 11 May 2020, Michael van Elst wrote:
We only trust a HWRNG and the seed file because only these enter
a non-zero value for entropy. I cannot configure any other source to
do that.
Why can't we allow the user to configure/enable estimation on a
per-source basis? The default can certain
On Mon, May 11, 2020 at 04:16:12PM -, Michael van Elst wrote:
> n...@netbsd.org (nia) writes:
>
> >is insisting). All of that depends on assumptions and trust - it
> >does no measurement of the value of the entropy being provided.
>
> Previously we could trust in random processes, whether the
On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson wrote:
>
> For the OpenBSD strategy to work, the system needs to actually refuse
> to run if the seed can't be loaded (or full entropy achieved in some
> other way). NetBSD doesn't do that. As long as there is any way
Well, no. The s
On Mon, May 11, 2020 at 09:53:31AM +0300, Andreas Gustafsson wrote:
>
> OpenBSD guarantees that there is an entropy seed from the boot loader,
> which is very different from NetBSD's "best effort". Was this not
> already the case when the getentropy API was introduced?
I think you need quotes ar
riastr...@netbsd.org (Taylor R Campbell) writes:
>> Date: Mon, 11 May 2020 16:16:12 - (UTC)
>> From: mlel...@serpens.de (Michael van Elst)
>>
>> Previously we could trust in random processes, whether the entropy
>> estimation was scientific or not. We could also chose what source
>> to trust.
> Date: Mon, 11 May 2020 16:16:12 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> Previously we could trust in random processes, whether the entropy
> estimation was scientific or not. We could also chose what source
> to trust.
Still can. NetBSD just doesn't do bogus pseudoscienti
n...@netbsd.org (nia) writes:
>is insisting). All of that depends on assumptions and trust - it
>does no measurement of the value of the entropy being provided.
Previously we could trust in random processes, whether the entropy
estimation was scientific or not. We could also chose what source
to
On Mon, May 11, 2020 at 05:58:21PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > For the OpenBSD strategy to work, the system needs to actually refuse
> > > to run if the seed can't be loaded (or full entropy achieved in some
> > > other way). NetBSD doesn't do that. As long
On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson wrote:
> For the OpenBSD strategy to work, the system needs to actually refuse
> to run if the seed can't be loaded (or full entropy achieved in some
> other way). NetBSD doesn't do that. As long as there is any way
> userland can start
Joerg Sonnenberger wrote:
> > For the OpenBSD strategy to work, the system needs to actually refuse
> > to run if the seed can't be loaded (or full entropy achieved in some
> > other way). NetBSD doesn't do that. As long as there is any way
> > userland can start before full entropy has been achi
On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson wrote:
> nia wrote:
> > > OpenBSD guarantees that there is an entropy seed from the boot loader,
> > > which is very different from NetBSD's "best effort". Was this not
> > > already the case when the getentropy API was introduced?
> >
nia wrote:
> > OpenBSD guarantees that there is an entropy seed from the boot loader,
> > which is very different from NetBSD's "best effort". Was this not
> > already the case when the getentropy API was introduced?
>
> We do the same, on supported architectures. In addition to reading
> from CP
On Mon, May 11, 2020 at 09:53:31AM +0300, Andreas Gustafsson wrote:
> OpenBSD guarantees that there is an entropy seed from the boot loader,
> which is very different from NetBSD's "best effort". Was this not
> already the case when the getentropy API was introduced?
We do the same, on supported
Taylor R Campbell wrote:
> > The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> > returns "high-quality" entropy, and do not caution against using it
> > for security critical purposes such as key generation, so presumably
> > applications do in fact use if for such purposes. G
On Sun, May 10, 2020 at 10:25:50PM +, Taylor R Campbell wrote:
> > Date: Sun, 10 May 2020 22:10:55 +
> > From: m...@netbsd.org
> >
> > I still don't find the getrandom man page you provided to be good, it
> > talks about "/dev/random behaviour" which is something you've changed to
> > not
> Date: Sun, 10 May 2020 22:10:55 +
> From: m...@netbsd.org
>
> I still don't find the getrandom man page you provided to be good, it
> talks about "/dev/random behaviour" which is something you've changed to
> not have this behaviour.
Can you be specific?
The phrase `/dev/random behaviour'
> That issue is why I'm not really happy about the getentropy API: it
> was originally defined to never block, and some systems have made it
> block for reasons that don't really mean very much.
>
> This is an argument for providing just getrandom -- the API contract
> is is clearer and doesn't re
> Date: Sun, 10 May 2020 14:24:00 +0300
> From: Andreas Gustafsson
>
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications d
nia wrote:
> For years, the development hivemind's advice has been "/dev/random bad!
> always urandom!", because having interfaces that unpredictably block on
> you is a terrible idea.
Yes, that has been the advice. I think it's bad advice, but it's
understandable given the historical /dev/random
On Sun, May 10, 2020 at 08:22:42PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > We don't warn people about unavailable of 127.0.0.1/:: during very early
> > boot and a number of other issues either. If your application is running
> > during system initialisation, you are suppose
Joerg Sonnenberger wrote:
> We don't warn people about unavailable of 127.0.0.1/:: during very early
> boot and a number of other issues either. If your application is running
> during system initialisation, you are supposed to be somewhat aware of
> the limitations in that case.
That's nonsense.
On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications do i
On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications do i
Taylor R Campbell wrote:
> In NetBSD-current, there's a distinction between:
> - incorporating what samples we have, and
> - confidently achieving full entropy.
> This distinction is made between sources that maybe might have
> entropy, like interrupt timings, but we can't honestly put a lower
> bo
> Date: Sun, 10 May 2020 07:44:36 +0200
> From: Michael van Elst
>
> On Sun, May 10, 2020 at 05:23:37AM +, Taylor R Campbell wrote:
> > But how is this question relevant to the discussion at hand of whether
> > to adopt a de facto standard C API or which?
>
> It isn't.
Then please take it
On Sun, May 10, 2020 at 05:23:37AM +, Taylor R Campbell wrote:
> >
> > >(Obviously, it is possible to run a kernel with an /etc/rc script that
> > >skips loading the seed from disk altogether; I'm not considering weird
> > >customized installations like that. System engineers who futz with
>
> Date: Sun, 10 May 2020 04:58:23 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> riastr...@netbsd.org (Taylor R Campbell) writes:
>
> >(Obviously, it is possible to run a kernel with an /etc/rc script that
> >skips loading the seed from disk altogether; I'm not considering weird
>
riastr...@netbsd.org (Taylor R Campbell) writes:
>(Obviously, it is possible to run a kernel with an /etc/rc script that
>skips loading the seed from disk altogether; I'm not considering weird
>customized installations like that. System engineers who futz with
>this are responsible for getting th
> Date: Sun, 10 May 2020 00:10:49 +
> From: m...@netbsd.org
>
> On Sat, May 09, 2020 at 10:56:51PM +, Taylor R Campbell wrote:
> > Given that, I think it is reasonable to implement getentropy(...) as
> > an alias for getrandom(..., GRND_INSECURE) == read from /dev/urandom
> > == sysctl ke
On Sat, May 09, 2020 at 10:56:51PM +, Taylor R Campbell wrote:
> Given that, I think it is reasonable to implement getentropy(...) as
> an alias for getrandom(..., GRND_INSECURE) == read from /dev/urandom
> == sysctl kern.arandom (as nia@ just committed the other day), which
> is consistent wi
> Date: Sun, 3 May 2020 21:43:15 +
> From: nia
>
> On Sun, May 03, 2020 at 09:28:37PM +, Taylor R Campbell wrote:
> > But on closer inspection, it's not clear there's a consensus on what
> > the semantics is supposed to be -- apparently _what_ everyone seems to
> > implement is slightly d
On Sun, May 03, 2020 at 09:28:37PM +, Taylor R Campbell wrote:
> > Date: Sun, 3 May 2020 19:13:23 +
> > From: nia
> >
> > Since most of the objections so far have been aimed at the design
> > and implementation of getrandom, does anyone have anything bad to say
> > about getentropy?
>
>
> Date: Sun, 3 May 2020 19:13:23 +
> From: nia
>
> Since most of the objections so far have been aimed at the design
> and implementation of getrandom, does anyone have anything bad to say
> about getentropy?
That's what I had in mind at the start of the thread after verifying
_that_ most ot
Since most of the objections so far have been aimed at the design
and implementation of getrandom, does anyone have anything bad to say
about getentropy?
If not, I'll commit it.
> Date: Sun, 3 May 2020 10:28:08 +0200
> From: Kurt Roeckx
>
> [OpenBSD] seem to use RDRAND when it's available in the bootloader, or
> something else when it's not. It's still my understanding that
> the bootloader is responisble for providing the entropy. You can
> argue that it might not conta
On Sun, May 03, 2020 at 10:48:41AM +0200, Kurt Roeckx wrote:
>
> You might want to read https://lwn.net/Articles/808575/
To be blunt (I think it's past time for it): I trust Taylor reading the
code more than I trust you reading stuff you found with Google.
Thor
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> +.It Dv GRND_INSECURE
> +Do not block; instead fill
> +.Fa buf
> +with output derived from whatever is in the system entropy pool so
> +far.
> +Equivalent to reading from
> +.Pa /dev/urandom ;
> +see
> +.Xr rnd 4 .
> +.Pp
> +If in
On Sun, May 03, 2020 at 12:05:22AM -0400, Thor Lancelot Simon wrote:
> On Sat, May 02, 2020 at 06:07:54PM +0200, Kurt Roeckx wrote:
> >
> > It's my understanding that it never blocks because the bootloader
> > provides entropy. Be time time the first user can call genentropy,
> > it has already be
On Sat, May 02, 2020 at 06:07:54PM +0200, Kurt Roeckx wrote:
>
> It's my understanding that it never blocks because the bootloader
> provides entropy. Be time time the first user can call genentropy,
> it has already been seeded.
Horsepuckey. You can't know the bootloader always has entropy to
p
On Sat, May 02, 2020 at 03:38:43PM +, Taylor R Campbell wrote:
> > Date: Sat, 2 May 2020 11:10:44 +0200
> > From: Kurt Roeckx
> >
> > On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> > >
> > > The alias getentropy(p,n) := getrandom(p,n,GRND_INSECURE)
> >
> > At several p
On Sat, May 02, 2020 at 04:31:43PM +, Taylor R Campbell wrote:
> > Date: Sat, 2 May 2020 18:07:54 +0200
> > From: Kurt Roeckx
> >
> > On Sat, May 02, 2020 at 03:38:43PM +, Taylor R Campbell wrote:
> > > > Date: Sat, 2 May 2020 11:10:44 +0200
> > > > From: Kurt Roeckx
> > > >
> > > > I h
> Date: Sat, 2 May 2020 18:07:54 +0200
> From: Kurt Roeckx
>
> On Sat, May 02, 2020 at 03:38:43PM +, Taylor R Campbell wrote:
> > > Date: Sat, 2 May 2020 11:10:44 +0200
> > > From: Kurt Roeckx
> > >
> > > I hink we've previously talked about it, and you said the OpenBSD
> > > manpage doesn'
> Date: Sat, 2 May 2020 12:22:20 +
> From: m...@netbsd.org
>
> The getrandom interface intentionally traps people to make questionable
> design choices.
I agree that the getrandom interface is not perfect, and I found the
Linux documentation rather confusing, but after having reimplemented
th
> Date: Sat, 2 May 2020 11:10:44 +0200
> From: Kurt Roeckx
>
> On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> >
> > The alias getentropy(p,n) := getrandom(p,n,GRND_INSECURE)
>
> At several places in your document you imply this. But
> getentropy(p,n) is more like getrandom
On Sat, May 02, 2020 at 02:27:31PM +0200, Martin Husemann wrote:
> On Sat, May 02, 2020 at 12:22:20PM +, m...@netbsd.org wrote:
> > Having compat shims in libc is as good as having compat shims in syscall
> > because it isn't possible to share raw syscall code between NetBSD and
> > other opera
On Sat, May 02, 2020 at 12:22:20PM +, m...@netbsd.org wrote:
> Having compat shims in libc is as good as having compat shims in syscall
> because it isn't possible to share raw syscall code between NetBSD and
> other operating systems -- our calling convention is different.
I can't parse that
For the previous discussion about it:
http://mail-index.netbsd.org/tech-crypto/2018/06/21/msg000763.html
This discussion calls for only having one interface, the
getrandom(...,0) one, which is the path other operating systems
took with their /dev/{,u}random.
The getrandom interface intentionally
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
>
> The alias getentropy(p,n) := getrandom(p,n,GRND_INSECURE)
At several places in your document you imply this. But
getentropy(p,n) is more like getrandom(p,n,0). That is, it also
waits until it's seeded, it only blocks a single
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> I propose that we additionally adopt getrandom and getentropy, two C
> APIs the world is converging on. For getentropy, this can be a simple
> userland wrapper in libc; for getrandom, this requires a new path into
> the kernel, a
> nia@ wrote the getentropy patch (probably needs a set list update too,
> and could use an automatic test); I wrote the getrandom patch.
> Feedback welcome!
My arguments for getentropy can be roughly summarized:
- It's just providing access to functionality already exposed to
userspace, but ma
74 matches
Mail list logo
