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 A7F903856DDE for ; Wed, 27 Jul 2022 20:15:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7F903856DDE 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 26RKFOGv020117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jul 2022 16:15:25 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 1D10E15C3434; Wed, 27 Jul 2022 16:15:24 -0400 (EDT) Date: Wed, 27 Jul 2022 16:15:24 -0400 From: "Theodore Ts'o" To: Florian Weimer Cc: Adhemerval Zanella Netto , Rich Felker , Yann Droneaud , "Jason A. Donenfeld" , libc-alpha@sourceware.org, linux-crypto@vger.kernel.org, Michael@phoronix.com, jann@thejh.net Subject: Re: arc4random - are you sure we want these? Message-ID: References: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org> <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: <87v8rid8ju.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_NONE, KAM_DMARC_STATUS, 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: Wed, 27 Jul 2022 20:15:44 -0000 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. What about the performance requirements? Designing an interface where the requirement "as fast as possible" is often not a great pathway to success, because the reality is that engineering is always about tradeoffs. If there are no security requirements (given the claim that some people want to put in the documentation disclaiming that arc4random might not be secure), why not just have people continue to use random(3)? - Ted