From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by sourceware.org (Postfix) with ESMTPS id 25B463858428 for ; Sun, 24 Jul 2022 21:57:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25B463858428 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 80976B80D85; Sun, 24 Jul 2022 21:57:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D8AEC3411E; Sun, 24 Jul 2022 21:57:17 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 60677a68 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sun, 24 Jul 2022 21:57:14 +0000 (UTC) Date: Sun, 24 Jul 2022 23:57:10 +0200 From: "Jason A. Donenfeld" To: Cristian =?utf-8?Q?Rodr=C3=ADguez?= Cc: libc-alpha@sourceware.org, Adhemerval Zanella Netto , Florian Weimer , Yann Droneaud , jann@thejh.net, Michael@phoronix.com, linux-crypto@vger.kernel.org Subject: Re: arc4random - are you sure we want these? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE, SPF_PASS, 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: Sun, 24 Jul 2022 21:57:22 -0000 Hi Cristian, On Sun, Jul 24, 2022 at 12:23:43PM -0400, Cristian Rodríguez wrote: > On Sat, Jul 23, 2022 at 6:59 PM Jason A. Donenfeld wrote: > > > Doesn't getrandom() already basically have this quality? > > In current kernels. yes. problems with old kernels remain.. Can you outline specifically which kernels you think those are and what the problems you think there are? And how arc4random as currently implemented does away with those problems? I kind of suspect you don't have something specific in mind... > The syscall > overhead being too high for some use cases is still a remaining > problem, Really? Do you have any numbers? I would be very surprised to hear that this is affecting things that intend to use arc4random as a substitute. Could you give me specifics on this? Again, this sounds made up in the absence of something real, widespread, and particular. > if that was overcomed it could be used literally for everything, > including simulations and other stuff. You mentioned simulations, but actually simulations are one thing where you want repeatable randomness -- something insecure with a seed that gives a good distribution and is extremely fast, so that you can repeat your simulation with the same data need-be. For this there are various LFSRs and such that work fine and are well explored. But that's not what getrandom() is, nor arc4random(). More generally speaking, there are well-defined RNGs that are for simulations and take seeds, and there are well-defined RNGs that are sufficient for crypto, and then there's a massive valley of ill-defined junk in between that people keep shooting themselves in the foot with. The fact that you won't even call arc4random cryptographically secure (according to Adhemerval's comment) indicates to me that something has gone wrong here. So, please, I urge you to put the breaks on this a little bit. Come up with numbers. Let's lay out the interfaces and properties we want. And then we'll see what we can draw up together. But now I'm just repeating myself. See my earlier reply here: https://lore.kernel.org/linux-crypto/Ytx8GKSZfRt+ZrEO@zx2c4.com/ Jason