Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1300366pxk; Fri, 2 Oct 2020 06:21:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGqxovBQuJQzdv15B//lcq9mqxw+qqUHZdM7xrFeX879EmIhk+ojZr0s7CFCt2oMdOu4wJ X-Received: by 2002:a17:906:f110:: with SMTP id gv16mr2282121ejb.257.1601644883700; Fri, 02 Oct 2020 06:21:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601644883; cv=none; d=google.com; s=arc-20160816; b=y4kfT//76cAyUUFxmHUzFMsvNy5jzYCbhHR4CbOE7s901yVUzG+4zyXMh0O+wHlB8J M5ENMDMK6db0Dg17OgIgkyv8168nxnPROlm21ZvyyWOLwpkVBawiNsb6kVlG+BdvpVBG HZYLJsK0vL1+jbEeBvV2o1NQ/ipti3m1ghvTVfjgh1rXoH0dor1uRwbEaFsHrM1YQfFX /NH961pQN2wWQYLtIAthtWxH/9oOzTByP/w+porbFTbS6c/xRLrvE0DihZzb+wHf/bB/ A+3IeOE50q+8w4X8XwKfPE/jO1VN+ZsJlm/Z5nrjKYsgEcnaWQrqD8ZCmXe10DBKqHbL ycPw== 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=9mOxvBM/wjIfMIIWjS4CbJnosSD0xETOj3M82beWwcE=; b=nUu3mK8Qyzmvxw/WLW3ro0U9pPgMh5akTSNrZbYa0sF3BYKdEZQKbxYOxpY8/FKC0F QfZJEwWapOqtkTLgTF78sCGQKVpBobPilQbcYabjWj4Ci6g8yRw47G9xcrnYRJj6ZEPy Y0tqGE0OhucM5ElbQKeKlcTt5jpyINisNCfqLf1dLGgGne6BxXcX82BaMKuQ5gW+pCLf fFhodnU8IAmIxmmz4Dfw1G2Ekyl7ednpG1ApWeylV32yaggbJEoMznko38Big/XWd2rh lPgHF5hliVqKGz4rZUrdA1qxtlk682mrlQdHH+mS2HKyX7ayVBWYB0eaVcei+1BaxAjT WsrQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 e3si917552edr.606.2020.10.02.06.20.52; Fri, 02 Oct 2020 06:21:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387877AbgJBNRJ (ORCPT + 99 others); Fri, 2 Oct 2020 09:17:09 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:42337 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733260AbgJBNRJ (ORCPT ); Fri, 2 Oct 2020 09:17:09 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 092DFt0G003851; Fri, 2 Oct 2020 15:15:55 +0200 Date: Fri, 2 Oct 2020 15:15:55 +0200 From: Willy Tarreau To: Torsten Duwe Cc: "Theodore Y. Ts'o" , linux-crypto@vger.kernel.org, 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 , "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: <20201002131555.GD3783@1wt.eu> References: <20200921075857.4424-1-nstange@suse.de> <20201002123836.GA14807@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201002123836.GA14807@lst.de> User-Agent: Mutt/1.6.1 (2016-04-27) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote: > 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. I think there's a small misunderstanding here, my understanding is that for quite a while, the possibilities offered by the various random subsystems or their proposed derivative used to range from "you have to choose between a fast system that may be vulnerable to some attacks, a system that might not be vulnerable to certain attacks but might not always boot, or a slow system not vulnerable to certain attacks". Greg's point seems to be that if we add an option, it means it's yet another tradeoff between these possibilities and that someone will still not be happy at the end of the chain. If the proposed solution covers everything at once (performance, reliability, unpredictability), then there probably is no more reason for keeping alternate solutions at all, hence there's no need to give the user the choice between multiple options when only one is known to always be valid. At least that's how I see it and it makes sense to me. > And this is all ??? Possibly a lot of people got used to seeing the numerous versions and are less attentive to new series, it's possible that your message will wake everyone up. Regards, Willy