linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org, Florian Weimer <fweimer@redhat.com>,
	Yann Droneaud <ydroneaud@opteya.com>,
	jann@thejh.net, Michael@phoronix.com,
	Paul Eggert <eggert@cs.ucla.edu>,
	linux-crypto@vger.kernel.org
Subject: Re: arc4random - are you sure we want these?
Date: Sun, 24 Jul 2022 00:54:16 +0200	[thread overview]
Message-ID: <Ytx8GKSZfRt+ZrEO@zx2c4.com> (raw)
In-Reply-To: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org>

Hi Adhemerval,

Thanks for your reply.

On Sat, Jul 23, 2022 at 02:39:29PM -0300, Adhemerval Zanella Netto wrote:
> > Firstly, for what use cases does this actually help? As of recent
> > changes to the Linux kernels -- now backported all the way to 4.9! --
> > getrandom() and /dev/urandom are extremely fast and operate over per-cpu
> > states locklessly. Sure you avoid a syscall by doing that in userspace,
> > but does it really matter? Who exactly benefits from this?
> 
> Mainly performance, since glibc both export getrandom and getentropy. 

Okay so your motivation is performance. But can you tell me what your
performance goals actually are? All kernel.org stable kernels from 4.9
and upwards now have really fast per-cpu lockless implementations of
getrandom() and /dev/urandom. If your goal is performance, I would be
very, very interested to find out a circumstance where this is
insufficient.

> There were some discussion on maillist and we also decided to explicit
> state this is not a CSRNG on our documentation.

Okay that's all the more reason why this is a completely garbage
endeavor. Sorry for the strong language, but the last thing anybody
needs is another PRNG that's "half way" between being good for crypto
and not. If it's not good for crypto, people will use it anyway,
especially since you're winking at them saying, "oh but actually
chacha20 is fine technically so....", and then fast-forward a few years
when you realize you can lean on your non-crypto commitment and make
things different. Never underestimate the power of a poorly defined
function definition. If your goal isn't to make a real CSPRNG, why make
this kind of thing at all?

And it's especially ridiculous since the OpenBSD arc4random *is* used
for crypto. So now you've really muddied the waters. (And naturally the
OpenBSD arc4random was done in conjunction with their kernel
development, since the same people work on both, which isn't what's
happened here.)

So your "it's a CSPRNG wink wink but the documentation says not, so
actually we're off the hook for doing this well" is a cop-out that will
lead to trouble.

Going back to my original point: what are the performance requirements
that point toward a userspace RNG being required here? If it's not
actually necessary, then let's not do this. If it is necessary for some
legitimate widespread reason, then let's do this right, and actually
make something you're comfortable calling cryptographically secure. And
let's get this right from the beginning, so that the new interface
doesn't come with all sorts of caveats, "this is safe for glibc ≥ 
4.3.2.1 only", or whatever else.

Again, I'm not adverse to the general concept. I just haven't seen
anything really justifying adding the complexity for it. And then
assuming that justification does exist somewhere, this approach doesn't
seem to be a particularly well planned one. As soon as you find yourself
reaching for the "documentation cop-out", something has gone amiss.

> The vDSO approach would be good think and if even the kernel provides it
> I think it would feasible to wire-up arc4random to use it if the  underlying
> kernel supports it.

So if you justify the performance requirement, wouldn't it make more
sense to just back getrandom() itself with a vDSO call? So that way,
kernels with that get bits faster (but by how much, really? c'mon...),
and kernels without it have things as normal as possible.

If your concern is instances in which getrandom() can fail, I'd like to
here what those concerns are so that interface can be fixed and
improved.

> But in the end I think if we are clear about in on the documentation,
> and provide alternative when the users are aware of the limitation, I do
> not think it is bad decision.

This really strikes me as an almost comically ominous expectation.
Design interfaces that don't have dangerous pitfalls. While
documentation might somehow technically absolve you of responsibility,
it doesn't actually help make the ecosystem safer by providing optimal
interfaces that don't have cop outs.

Anyway, to reiterate:

- Can you show me some concerning performance numbers on the current
  batch of kernel.org stable kernels, and the use cases for which those
  numbers are concerning, and how widespread you think those use cases
  are?

- If this really *is* necessary for some reason, can we do it well out
  of the gate, with good coordination between kernel and userland,
  instead of half-assing it initially and covering that up with a
  documentation note?

Jason

  reply	other threads:[~2022-07-23 22:54 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-23 16:22 arc4random - are you sure we want these? Jason A. Donenfeld
2022-07-23 16:25 ` Jason A. Donenfeld
2022-07-23 17:18   ` Paul Eggert
2022-07-24 23:55     ` Jason A. Donenfeld
2022-07-25 20:31       ` Paul Eggert
2022-07-23 17:39   ` Adhemerval Zanella Netto
2022-07-23 22:54     ` Jason A. Donenfeld [this message]
2022-07-25 15:33     ` Rich Felker
2022-07-25 15:59       ` Adhemerval Zanella Netto
2022-07-25 16:18       ` Sandy Harris
2022-07-25 16:40       ` Florian Weimer
2022-07-25 16:51         ` Jason A. Donenfeld
2022-07-25 17:44         ` Rich Felker
2022-07-25 18:33           ` Cristian Rodríguez
2022-07-25 18:49             ` Rich Felker
2022-07-25 18:49               ` Rich Felker
     [not found]               ` <YuCa1lDqoxdnZut/@mit.edu>
     [not found]                 ` <a5b6307d-6811-61b6-c13d-febaa6ad1e48@linaro.org>
     [not found]                   ` <YuEwR0bJhOvRtmFe@mit.edu>
2022-07-27 12:49                     ` Florian Weimer
2022-07-27 20:15                       ` Theodore Ts'o
2022-07-27 21:59                         ` Rich Felker
2022-07-28  0:30                           ` Theodore Ts'o
2022-07-28  0:39                         ` Cristian Rodríguez
2022-07-23 19:04   ` Cristian Rodríguez
2022-07-23 22:59     ` Jason A. Donenfeld
2022-07-24 16:23       ` Cristian Rodríguez
2022-07-24 21:57         ` Jason A. Donenfeld
2022-07-25 10:14     ` Florian Weimer
2022-07-25 10:11   ` Florian Weimer
2022-07-25 11:04     ` Jason A. Donenfeld
2022-07-25 12:39       ` Florian Weimer
2022-07-25 13:43         ` Jason A. Donenfeld
2022-07-25 13:58           ` Cristian Rodríguez
2022-07-25 16:06           ` Rich Felker
2022-07-25 16:43             ` Florian Weimer
2022-07-26 14:27         ` Overwrittting AT_RANDOM after use (was Re: arc4random - are you sure we want these?) Yann Droneaud
2022-07-26 14:35         ` arc4random - are you sure we want these? Yann Droneaud
2022-07-25 13:25       ` Jeffrey Walton
2022-07-25 13:48         ` Jason A. Donenfeld
2022-07-25 14:56     ` Rich Felker
2022-07-25 22:57   ` [PATCH] arc4random: simplify design for better safety Jason A. Donenfeld
2022-07-25 23:11     ` Jason A. Donenfeld
2022-07-25 23:28     ` [PATCH v2] " Jason A. Donenfeld
2022-07-25 23:59       ` Eric Biggers
2022-07-26 10:26         ` Jason A. Donenfeld
2022-07-26  1:10       ` Mark Harris
2022-07-26 10:41         ` Jason A. Donenfeld
2022-07-26 11:06           ` Florian Weimer
2022-07-26 16:51           ` Mark Harris
2022-07-26 18:42             ` Jason A. Donenfeld
2022-07-26 19:24               ` Jason A. Donenfeld
2022-07-26  9:55       ` Florian Weimer
2022-07-26 11:04         ` Jason A. Donenfeld
2022-07-26 11:07           ` [PATCH v3] " Jason A. Donenfeld
2022-07-26 11:11             ` Jason A. Donenfeld
2022-07-26 11:12           ` [PATCH v2] " Florian Weimer
2022-07-26 11:20             ` Jason A. Donenfeld
2022-07-26 11:35               ` Adhemerval Zanella Netto
2022-07-26 11:33       ` Adhemerval Zanella Netto
2022-07-26 11:54         ` Jason A. Donenfeld
2022-07-26 12:08           ` Jason A. Donenfeld
2022-07-26 12:20           ` Jason A. Donenfeld
2022-07-26 12:34           ` Adhemerval Zanella Netto
2022-07-26 12:47             ` Jason A. Donenfeld
2022-07-26 13:11               ` Adhemerval Zanella Netto
2022-07-26 13:30     ` [PATCH v4] " Jason A. Donenfeld
2022-07-26 15:21       ` Yann Droneaud
2022-07-26 16:20       ` Adhemerval Zanella Netto
2022-07-26 18:36         ` Jason A. Donenfeld
2022-07-26 19:08       ` [PATCH v5] " Jason A. Donenfeld
2022-07-26 19:58         ` [PATCH v6] " Jason A. Donenfeld
2022-07-26 20:17           ` Adhemerval Zanella Netto
2022-07-26 20:56             ` Adhemerval Zanella Netto
2022-07-28 10:29           ` Szabolcs Nagy
2022-07-28 10:36             ` Szabolcs Nagy
2022-07-28 11:01               ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ytx8GKSZfRt+ZrEO@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=Michael@phoronix.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=jann@thejh.net \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=ydroneaud@opteya.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).