Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 27 Jul 2022 20:30:12 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Rich Felker <dalias@libc.org>
Cc:     Florian Weimer <fweimer@redhat.com>,
        Yann Droneaud <ydroneaud@opteya.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, libc-alpha@sourceware.org,
        Michael@phoronix.com, linux-crypto@vger.kernel.org, jann@thejh.net
Subject: Re: arc4random - are you sure we want these?
Message-ID: <YuHYlIXR0wsjyjIY@mit.edu>
References: <878rohp2ll.fsf@oldenburg.str.redhat.com>
 <20220725174430.GI7074@brightrain.aerifal.cx>
 <CAPBLoAe89Pwt=F_jcZirVXQA7JtugV+5+BWHBt0RaZka1y0K=g@mail.gmail.com>
 <20220725184929.GJ7074@brightrain.aerifal.cx>
 <YuCa1lDqoxdnZut/@mit.edu>
 <a5b6307d-6811-61b6-c13d-febaa6ad1e48@linaro.org>
 <YuEwR0bJhOvRtmFe@mit.edu>
 <87v8rid8ju.fsf@oldenburg.str.redhat.com>
 <YuGc3O88Zxb5HkxY@mit.edu>
 <20220727215949.GM7074@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220727215949.GM7074@brightrain.aerifal.cx>
Precedence: bulk

On Wed, Jul 27, 2022 at 05:59:49PM -0400, Rich Felker wrote:
> The only place I've heard of a viable "soft requirement" for real
> entropy is for salting the hash function used in hash table maps to
> harden them against DoS via intentional collisions. This is a small
> but arguably legitimate usage domain.

OK, so this is an issue that both Perl and Python have had to deal
with, as described here: https://lwn.net/Articles/474912/

Is that fair description of the use case which you are describing?
Because if it is, in the worst case, we only need a single random
value for every http request made to the server.  Would you agree with
that?

I think you'll find that even the original getrandom(2) system call or
fetching a random value from /dev/urandom was plenty fast enough for
this particular use case.  If you're on some slow, ancient CPU, the
webserver isn't going to be able to handle that many queries per
second.  And if you're on a fast CPU, the original /dev/urandom and/or
getrandom(2) system call would be plenty fast enough.

This is why both Jason and I have been trying to push people to
clearly articular a specific use case and the attendant performance
requirement, so we can test the hypothesis regarding how critical it
is to have an userspace cryptographically secure RNG, with all of the
attendant opportunities for security vulnerabilities in the face of VM
snapshots, or VM's getting duplicated with a pre-spun execution image,
etc., etc.

Cheers,

					- Ted