From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id CC0CD385829F for ; Wed, 27 Jul 2022 21:59:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC0CD385829F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Wed, 27 Jul 2022 17:59:49 -0400 From: Rich Felker To: Theodore Ts'o Cc: Florian Weimer , Yann Droneaud , "Jason A. Donenfeld" , 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: <20220727215949.GM7074@brightrain.aerifal.cx> References: <20220725153303.GF7074@brightrain.aerifal.cx> <878rohp2ll.fsf@oldenburg.str.redhat.com> <20220725174430.GI7074@brightrain.aerifal.cx> <20220725184929.GJ7074@brightrain.aerifal.cx> <87v8rid8ju.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TVD_SUBJ_NUM_OBFU_MINFP, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2022 21:59:52 -0000 On Wed, Jul 27, 2022 at 04:15:24PM -0400, Theodore Ts'o via Libc-alpha wrote: > On Wed, Jul 27, 2022 at 02:49:57PM +0200, Florian Weimer wrote: > > * Theodore Ts'o: > > > > > But even if you didn't take the latest kernels, I think you will find > > > that if you actually benchmark how many queries per second a real-life > > > secure web server or VPN gateway, even the original 5.15.0 /dev/random > > > driver was plenty fast enough for real world cryptographic use cases. > > > > The idea is to that arc4random() is suitable in pretty much all places > > that have historically used random() (outside of deterministic > > simulations). Straight calls to getrandom are much, much slower than > > random(), and it's not even the system call overhead. > > What are those places? And what are their performance and security > requirements? I've heard some people claim that arc4random() is > supposed to provide strong security guarantees. I've heard others > claim that it doesn't, or at least glibc was planning on disclaiming > security guaranteees. So there seems to be a lack of clarity about > the security requirements. 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. Most use of random() is not this, and should not be this -- the value of deterministic execution for ability to reproduce crashes, debug, etc. is real, and the value of actual entropy vs a deterministic-seeded prng is imaginary. The purpose of arc4random has always been *cryptographically secure* entropy, not "gratuitously replace random() and break reproducible behavior because the programmer does not understand the difference". Nobody should be advocating for using these functions for anything except secure secrets. Rich