Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1271263pxk; Fri, 2 Oct 2020 05:39:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJGdzXgXaKjjK9tCXeGJX3AlBI/mBG9LvHkPQQKBrqF8NWoJhrXqlQ4+bdssyK1fFKKDi6 X-Received: by 2002:a50:8e58:: with SMTP id 24mr2133991edx.226.1601642394618; Fri, 02 Oct 2020 05:39:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601642394; cv=none; d=google.com; s=arc-20160816; b=pLE6wSMUk6rT73Q3WZXfO3oKKN3kq4WK9t+WLmuLHZPn3hcMc9PZxwcRLVXaUJHPiN a166mo8FwqgjEBA6IBstC86TyZV8VSG599LDcPFR2K4/gJ3nV4cRDb8q4g46tSN4aako zMkpmIGH9UOWp3Fyg/g8QPFBv0LH4PGVIGN0q/0HY6q6G/uKM+aWs5rk56/iS9Ya4nqz iOabu8s2v93pSXR4fgaiE17Fn7qiu7hOX7q5EQfcxjfMew9iirE1mW6Ajt8JaGkB51bH /hbJJK5PVQnUDRr32vswglMxrgOjjsRC70uAVqVmGwen+4ctVEUaeJ+6oa0kIG5BXnB5 tDJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=g8hVC7+FNW5kM7ppKS8aE2Fg3Dc80Azdgjzhq45BOAM=; b=f0DxyI+JOBUsQPnblT8ZWw3R79jm0dYBU6cZLdnPCd2eugXyg0XwSIamn58F1cw4Fo 2KLW1AcEMW9uS0uFuWfTVrs0v5dmbMog8Sbvixh8PePbnV0Ex/Huism1Tk+eFa/XzhC5 AWjEmNlicbJHnxAzIc62EOWHWgJGEIy5wWdYagyPQA9kFf5Y25jMWzkEot8OOE+W/lc+ uLDBmwtuiFjz34jhVXV3avycsmD55+pwOw5uRWov2iE0QGVk0vmDYbBTZMujegHtU5/n r9lObfdk4/9nVtv3v0KTt9SCZpuzxSV9OXzthTQn6v0mHRkAdURMRglIgaG/Iw3pHzew Wsyg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si924049ejd.663.2020.10.02.05.39.23; Fri, 02 Oct 2020 05:39:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726176AbgJBMjV (ORCPT + 99 others); Fri, 2 Oct 2020 08:39:21 -0400 Received: from verein.lst.de ([213.95.11.211]:52210 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726017AbgJBMjV (ORCPT ); Fri, 2 Oct 2020 08:39:21 -0400 Received: by verein.lst.de (Postfix, from userid 107) id 258BB68C4E; Fri, 2 Oct 2020 14:39:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on verein.lst.de X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED,BAYES_50 autolearn=disabled version=3.3.1 Received: from lst.de (p5b0d8779.dip0.t-ipconnect.de [91.13.135.121]) by verein.lst.de (Postfix) with ESMTPSA id 90E8467354; Fri, 2 Oct 2020 14:38:40 +0200 (CEST) Date: Fri, 2 Oct 2020 14:38:36 +0200 From: Torsten Duwe To: "Theodore Y. Ts'o" Cc: linux-crypto@vger.kernel.org, Nicolai Stange , LKML , Arnd Bergmann , Greg Kroah-Hartman , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Willy Tarreau , 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 , "Jason A. Donenfeld" , Stephan =?iso-8859-1?Q?M=FCller?= , Petr Tesarik Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance Message-ID: <20201002123836.GA14807@lst.de> References: <20200921075857.4424-1-nstange@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921075857.4424-1-nstange@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Almost two weeks passed and these are the "relevant" replies: Jason personally does not like FIPS, and is afraid of "subpar crypto". Albeit this patch set strictly isn't about crypto at all; the crypto subsystem is in the unlucky position to just depend on a good entropy source. Greg claims that Linux (kernel) isn't about choice, which is clearly wrong. And this is all ??? There are options for stack protection. I can see bounds checking and other sanity checks all over the place. And doing a similar thing on entropy sources is a problem? Admittedly, if entropy sources fail, the kernel will happily remain running. No bad immediate effects in userland will arise. Only some cryptographic algorithms, otherwise very decent, will run on unneccessarily weak keys, probably causing some real-world problems. Does anybody care? The NIST and the BSI do, but that does not mean their solutions are automatically wrong or backdoored. There is now a well layed-out scheme to ensure quality randomness, and a lot of work here has been put into its implementation. Would some maintainer please comment on potential problems or shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO. Torsten