From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by sourceware.org (Postfix) with ESMTPS id C2AC93875A24 for ; Mon, 25 Jul 2022 16:51:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2AC93875A24 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 dfw.source.kernel.org (Postfix) with ESMTPS id 6143161333; Mon, 25 Jul 2022 16:51:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C42F2C341CE; Mon, 25 Jul 2022 16:51:40 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id cb71a268 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 25 Jul 2022 16:51:38 +0000 (UTC) Date: Mon, 25 Jul 2022 18:51:36 +0200 From: "Jason A. Donenfeld" To: Florian Weimer Cc: Rich Felker , Adhemerval Zanella Netto , libc-alpha@sourceware.org, Yann Droneaud , jann@thejh.net, Michael@phoronix.com, Paul Eggert , linux-crypto@vger.kernel.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <878rohp2ll.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-2.6 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: Mon, 25 Jul 2022 16:51:44 -0000 Hi Florian, On Mon, Jul 25, 2022 at 06:40:54PM +0200, Florian Weimer wrote: > The core issue is that on some kernels/architectures, reading from > /dev/urandom can degrade to GRND_INSECURE (approximately), and while the > result is likely still unpredictable, not everyone would label that as a > CSPRNG. On some old kernels (though I think not all?), you can poll on /dev/random. This isn't perfect, as the ancient "non blocking pool" initialized after the "blocking pool", but it's not too imperfect either. Take a look at the previously linked random-util.c. > If we document arc4random as a CSPRNG, this means that we would have to > ditch the fallback code and abort the process if the getrandom system > call is not available: when reading from /dev/urandom as a fallback, we > have no way of knowing if we are in any of the impacted execution > environments. Based on your other comments, it seems that you are > interested in such fallbacks, too, but I don't think you can actually > have both (CSPRNG + fallback). > > And then there is the certification issue. We really want applications > that already use OpenSSL for other cryptography to use RAND_bytes > instead of arc4random. Likewise for GNUTLS and gnutls_rnd. What should > authors of those cryptographic libraries? That's less clear, and really > depends on the constraints they operate in (e.g., they may target only a > subset of architectures and kernel versions). I think all of this is yet another indication that there are some major things to work out -- should we block or not? is buffering safe? is the interface correct? -- and so we should just back out the arc4random commit until this has been explored a bit more. We're not gaining anything from rushing this, especially as a "source code compatibility" thing, if there's not even agreement between OSes on what the function does inside. Jason PS: please try to keep linux-crypto@vger.kernel.org CC'd. I've been bouncing these manually when not, but it's hard to keep up with that.