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 07EF6C433EF for ; Mon, 10 Jan 2022 19:51:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241338AbiAJTvP (ORCPT ); Mon, 10 Jan 2022 14:51:15 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:49309 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S239531AbiAJTvP (ORCPT ); Mon, 10 Jan 2022 14:51:15 -0500 Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20AJnORK019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jan 2022 14:49:25 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id D0A2A15C00C8; Mon, 10 Jan 2022 14:49:24 -0500 (EST) Date: Mon, 10 Jan 2022 14:49:24 -0500 From: "Theodore Ts'o" To: "Jason A. Donenfeld" Cc: Marcelo Henrique Cerri , Simo Sorce , Greg Kroah-Hartman , Jeffrey Walton , Stephan Mueller , Linux Crypto Mailing List , Willy Tarreau , Nicolai Stange , LKML , Arnd Bergmann , "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 , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Petr Tesarik , John Haxby , Alexander Lobakin , Jirka Hladky , Eric Biggers Subject: Re: [PATCH v43 01/15] Linux Random Number Generator Message-ID: References: <20211210014337.xmin2lu5rhhe3b3t@valinor> <20220110132349.siplwka7yhe2tmwc@valinor> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jan 10, 2022 at 07:44:23PM +0100, Jason A. Donenfeld wrote: > b) Userspace to use some other RNG. > > (b) can be accomplished in userspace by just (i) disabling getrandom() > (making it return ENOSYS), and then (ii) replacing the /dev/urandom > path with a CUSE device or similar. I don't think you even need to do this. In general, you need FIPS certification for some specific use cases / application. For example, if you're going for PCI compliance, then you might only need FIPS compliance for your OpenSSL library. What the FIPS certification lab might consider acceptable for its entropy for its DRBG is an interesting question. For some, simply having the OpenSSL library use RDSEED or RDRAND might be sufficient. Or it could talk to an actual physical RNG device. So disabling getrandom() is probably not necessary, just so long as you can demonstrate that the FIPS cryptographic module --- i.e., the OpenSSL library --- is getting its entropy from an acceptable source. I suspect what's actually going on is that some enterprise customers have FIPS complaince on a check-off list, and they aren't actually getting a formal FIPS certification. Or they only need something to wave under the noses of their PCI certification company, and so the question is what makes them happy. Going into the details of whether ChaCha20 is blessed by FIPS is probably more into technical weeds than most of the people who *say* they want FIPS certification actually will go. After all, the in-kernel DRBG is using as its "entropy source" the timing instructions from a bunch of x86 assembly instructions which is **soooo** complicated that people are willing to drink from the snake oil and claim that it is secure. Is it really? Has FIPS said that it's OK? Not any more than they've said anything about ChaCha20! And this is why some FIPS certification have gotten by just *fine* with a pure userspace OpenSSL library as their FIPS cryptographic module. Where you draw the line between a "blessed" entropy source and one that's just hand-waving is really at the discretion of the certification lab. Personally, if I was doing something that I really, *really* wanted to be secure, I'd be mixing in several hardware RNG's. Given that most server and client platforms have a TPM, or some other hardened security module, using that is probably the best bet of I was architecting some that *really* needed to be secure. But of course, we're not talking about real security in this thread; we're talking about whatever security theater will make the FIPS certification labs, and the people who say they want FIPS on their check-off list, happy. :-) - Ted