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 063BB3853575 for ; Sun, 24 Jul 2022 23:55:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 063BB3853575 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 00046B80DCD; Sun, 24 Jul 2022 23:55:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 414CBC3411E; Sun, 24 Jul 2022 23:55:44 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id b80287cb (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sun, 24 Jul 2022 23:55:42 +0000 (UTC) Date: Mon, 25 Jul 2022 01:55:40 +0200 From: "Jason A. Donenfeld" To: Paul Eggert Cc: libc-alpha@sourceware.org, linux-crypto@vger.kernel.org Subject: Re: arc4random - are you sure we want these? Message-ID: References: <555f2208-6a04-8c3c-ea52-41ad02b33b0c@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <555f2208-6a04-8c3c-ea52-41ad02b33b0c@cs.ucla.edu> 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 23:55:48 -0000 Hi Paul, Sorry I missed your reply earlier. I'm not a subscriber so I missed this as I somehow fell out of the CC. On Sat, Jul 23, 2022 at 05:18:05PM +0000, Paul Eggert wrote: > On 7/23/22 09:25, Jason A. Donenfeld via Libc-alpha wrote: > > it's hard to recommend that anybody really use these functions. > > Just keep using getrandom(2), which has mostly favorable semantics. > > Yes, that's what I plan to do in GNU projects like Coreutils and Emacs. > > Although I don't recommend arc4random, I suppose it was added for > source-code compatibility with the BSDs (I wasn't involved in the decision). Source code compatibility isn't exactly a bad goal. But according to Adhemerval you don't plan on this being a secure thing -- hence mentioning as such in the documentation as he mentioned -- so it seems like a maybe-okay goal gone bad. But, anyway, if the goal is just basic source code compatibility, back it with simple calls to getrandom() to start, and if later there are performance issues (big if!), we can look into vDSO tricks and such to speed that up. There's no need to add a whole new huge fraught mechanism for that. > > is there anyway that glibc can *not* do this, or has that > > ship fully sailed > > It hasn't fully sailed since we haven't done a release. Well that's good. I'd recommend just backing it out until it can be done in a way that glibc developers feel comfortable calling safe (and others too, of course, but at the very least you don't want to start out making something you feel the need to warn about in the documentation). > That's a bit harsh. Coreutils still has its own random number generator > because it needed to be portable to a bunch of platforms and there was > no standard. Eventually we'll rip it out but there's no rush. Having > written much of that code I can reliably assert that it was not fun. I'm happy to help with this if you need. I recently cleaned up some stuff similar sounding in systemd for their uses; random-util.c there might be of interest. Jason