Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E637C433EF for ; Mon, 22 Nov 2021 05:36:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231253AbhKVFjM (ORCPT ); Mon, 22 Nov 2021 00:39:12 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.81]:12322 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229983AbhKVFjL (ORCPT ); Mon, 22 Nov 2021 00:39:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1637559287; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=i7W+1Ainme/lgyEWP1ffFGfij4ISOJoBz/F7UBXS9sw=; b=sXSjU4exn0Iolbg/MfP7GdUjWb+2juATn6mfFPSknQk1iwOZhskJ84WAjHCVFrUJnd rWQ3k8OoQXlwLFfMbKQ9OWbR3Ne5KhotpXwkHMxBOuFgQgq4bqIoOfxcFd4oukB5fKqx cDv9bdTzvOeJlfklTvSdxHebiN98mejF9olqCInsc1LA2SZI4xb7gN8tANZYiXvqeZVQ gL9csV1HzTEgNDlXmvBi7pcUDRs+OrVBdJ1X9BZQ5juJnuG63WtrdRUDt/9MC534VFpb jRHCA6EnkoS8eTKutAJkTQHjxgfyCG94ujJ7dRk4E/HAb0Z+SulQjCAm3+Qb3XPwsh4i Tfew== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzGHXPZIfSfAhhe" X-RZG-CLASS-ID: mo00 Received: from tauon.chronox.de by smtp.strato.de (RZmta 47.34.5 DYNA|AUTH) with ESMTPSA id U02dfbxAM5Yh4Wa (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 22 Nov 2021 06:34:43 +0100 (CET) From: Stephan Mueller To: "Jason A. Donenfeld" Cc: Tso Ted , linux-crypto@vger.kernel.org, Willy Tarreau , Nicolai Stange , LKML , Arnd Bergmann , Greg Kroah-Hartman , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Peter Matthias , Marcelo Henrique Cerri , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Eric Biggers , Petr Tesarik , John Haxby , Alexander Lobakin , Jirka Hladky Subject: Re: [PATCH v43 01/15] Linux Random Number Generator Date: Mon, 22 Nov 2021 06:34:43 +0100 Message-ID: <2560758.ogP2UNPRoF@tauon.chronox.de> In-Reply-To: References: <2036923.9o76ZdvQCi@positron.chronox.de> <4641592.OV4Wx5bFTl@positron.chronox.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Sonntag, 21. November 2021, 23:42:33 CET schrieb Jason A. Donenfeld: Hi Jason, > Hi Stephan, > > You've posted it again, and yet I still believe this is not the > correct design or direction. I do not think the explicit goal of > extended configurability ("flexibility") or the explicit goal of being > FIPS compatible represent good directions, and I think this introduces > new problems rather than solving any existing ones. The members from the Linux distributions that are on copy on this may tell you a different story. They all developed their own downstream patches to somehow add the flexibility that is needed for them. So, we have a great deal of fragmentation at the resting-foundation of Linux cryptography. Then the implementation of the flexibility in the LRNG is done such that irrespecitve of which options are selected, the LRNG operates always at a secure state. > While there are > ways the current RNG could or even should be improved -- or rewritten > -- this approach is still not that, no matter how many times you post > it. It is almost as though you hope this somehow gets accepted through > a general apathy that might develop by the 1000th revision, when > cranks like me and others no longer have the motivation to keep > responding with the same thing. But here we are again. > > My own experience pushing something that didn't have substantial > enough buy-in from existing maintainers (the Zinc crypto library) > ultimately led me to stop pushing in order to not alienate folks, step > back, and listen a bit. Eventually somebody reached out to work with > me (Ard) and we submitted a good compromise collaboration that we all > generally felt better about. In this case, your cryptographic design > tastes are sufficiently divergent from mine that I'm not sure how far > such a thing would go, but it also seems to me that continually > pushing the same thing over and over isn't winning you any points here > either. Submission by attrition is not an outcome anybody should want. > > Sorry to be so blunt. It's just that my, "I don't like this" is the > same as it was the last time, and I'm not aware of anything > significant in that area changing this time. I have received numerous technical comments from various Linux developers. All were integrated. None of these comments hinted to requestes in changing the design. That said, even when you refer to already suggested architectural differnces, I yet have to first receive them, > > Jason Ciao Stephan