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 C057E3875A22 for ; Mon, 25 Jul 2022 13:48:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C057E3875A22 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 44596611C0; Mon, 25 Jul 2022 13:48:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4455EC341C6; Mon, 25 Jul 2022 13:48:11 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 9016ef83 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 25 Jul 2022 13:48:09 +0000 (UTC) Date: Mon, 25 Jul 2022 15:48:07 +0200 From: "Jason A. Donenfeld" To: Jeffrey Walton Cc: Linux Crypto Mailing List , libc-alpha@sourceware.org Subject: Re: arc4random - are you sure we want these? Message-ID: References: <87bktdsdrk.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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: Mon, 25 Jul 2022 13:48:14 -0000 Hi Jeffrey, Please keep libc-alpha@sourceware.org CC'd. On Mon, Jul 25, 2022 at 09:25:58AM -0400, Jeffrey Walton wrote: > On Mon, Jul 25, 2022 at 7:08 AM Jason A. Donenfeld wrote: > > ... > > > The performance numbers suggest that we benefit from buffering in user > > > space. > > > > The question is whether it's safe and advisable to buffer this way in > > userspace. Does userspace have the right information now of when to > > discard the buffer and get a new one? I suspect it does not. > > I _think_ the sharp edge on userspace buffering is generator state. > Most generator threat models I have seen assume the attacker does not > know the generator's state. If buffering occurs in the application, > then it may be easier for an attacker to learn of the generator's > state. If buffering occurs in the kernel, then generator state should > be private from an userspace application's view. I guess that's one concern, if you're worried about heartbleed-like attacks, in which an undetected RNG state compromise might be easier to pull off. What I have in mind, though, are the various triggers and heuristics that the kernel uses for when it needs to reseed. These userspace doesn't know about. Jason