From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by sourceware.org (Postfix) with ESMTPS id 69FD3385829F for ; Thu, 28 Jul 2022 00:30:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 69FD3385829F Received: from cwcc.thunk.org (pool-173-48-118-63.bstnma.fios.verizon.net [173.48.118.63]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 26S0UCCS031326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jul 2022 20:30:13 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id CBC0315C3AE2; Wed, 27 Jul 2022 20:30:12 -0400 (EDT) Date: Wed, 27 Jul 2022 20:30:12 -0400 From: "Theodore Ts'o" To: Rich Felker 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: References: <878rohp2ll.fsf@oldenburg.str.redhat.com> <20220725174430.GI7074@brightrain.aerifal.cx> <20220725184929.GJ7074@brightrain.aerifal.cx> <87v8rid8ju.fsf@oldenburg.str.redhat.com> <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> X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, 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: Thu, 28 Jul 2022 00:30:30 -0000 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