From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1CE77385840F for ; Mon, 25 Jul 2022 16:41:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1CE77385840F Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-568-BPOKelYoPqWY0Vz1x19xkw-1; Mon, 25 Jul 2022 12:40:59 -0400 X-MC-Unique: BPOKelYoPqWY0Vz1x19xkw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E0EBB94F663; Mon, 25 Jul 2022 16:40:58 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.195]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C894F492C3B; Mon, 25 Jul 2022 16:40:56 +0000 (UTC) From: Florian Weimer To: Rich Felker Cc: Adhemerval Zanella Netto , "Jason A. Donenfeld" , libc-alpha@sourceware.org, Yann Droneaud , jann@thejh.net, Michael@phoronix.com, Paul Eggert Subject: Re: arc4random - are you sure we want these? References: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org> <20220725153303.GF7074@brightrain.aerifal.cx> Date: Mon, 25 Jul 2022 18:40:54 +0200 In-Reply-To: <20220725153303.GF7074@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 25 Jul 2022 11:33:04 -0400") Message-ID: <878rohp2ll.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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:41:07 -0000 * Rich Felker: > On Sat, Jul 23, 2022 at 02:39:29PM -0300, Adhemerval Zanella Netto via Libc-alpha wrote: >> On 23/07/22 13:25, Jason A. Donenfeld wrote: >> > Firstly, for what use cases does this actually help? As of recent >> > changes to the Linux kernels -- now backported all the way to 4.9! -- >> > getrandom() and /dev/urandom are extremely fast and operate over per-cpu >> > states locklessly. Sure you avoid a syscall by doing that in userspace, >> > but does it really matter? Who exactly benefits from this? >> >> Mainly performance, since glibc both export getrandom and getentropy. >> There were some discussion on maillist and we also decided to explicit >> state this is not a CSRNG on our documentation. > > This is an extreme documentation/specification bug that *hurts* > portability and security. The core contract of the historical > arc4random function is that it *is* a CSPRNG. Having a function by > that name that's allowed not to be one means now all software using it > has to add detection for the broken glibc variant. > > If the glibc implementation has flaws that actually make it not a > CSPRNG, this absolutely needs to be fixed. Not doing so is > irresponsible and will set everyone back a long ways. 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. 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). Thanks, Florian