Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2512495ybl; Thu, 9 Jan 2020 14:11:07 -0800 (PST) X-Google-Smtp-Source: APXvYqw57gotO2MxDQsLIo//CZNhpgzlSggqKrwPOLVL1kQAtgv4BA6VvMD7dV4invnl13hu4WkH X-Received: by 2002:a05:6808:aba:: with SMTP id r26mr4828514oij.4.1578607867026; Thu, 09 Jan 2020 14:11:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578607867; cv=none; d=google.com; s=arc-20160816; b=1F7waF/fIemBh9LmrsYNFRIs7HdCqO1UVlmYW0jzv29rp/uljPbbcEV1ql/r3NLnmV R4ar5FKl7fAI7x9clJF1zwCMnno6JDMhb2LPcJSc6StyQJOtCgFcRGqqw9D/FAfWu6PD DNtevMg1qUtNgJ/5Ej3dlEcTPxYVlDTTYpHLZUjexOFSPEIw8U7zCBgnYfsTP6EUe/HE YZQx9pjhH+Ibg34lt6w5OfmPj3kU+sXmiahamCdZRJkh29Orj2t4Q7TSoUziK9ZQ2U3Z 9xL2g2L0DLG7RJ0i/zKXksAfxNTR0sgMdX6B3PmyaSI1rE2r8tWchcCCSRpXrDmkOCVc N6/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=NykEEw3tWd8mGC0/CUPO+dyaSnzEFOgOboOLGdBNKPo=; b=zTKyIVJMbF8QaljV7+9YEe70PYc+JuwT//qMYaJefP5U0GqPpAfqavhk48KJUbJ2Hb MUs9oxCAs0xRGktWctYzev3h8iRBIIYz5PNvmBdPrgdKw0WwivnYAN7rKHIVPFHrEK2u 6K4JQ72Dvt1wIdfKJYbndQ1CLD7bs/wbwC2XUY6hxekI+lDEfYbv2rJy80+V6o/fOGeY S2WPnSn/x/kuPaof0OzCQrCUtfWoOlGgpTXqFr73I/P2WlOUxes13H3yfxpNEYJcBgt2 6I/VaoY+LMqM1dbtU5K0YHPMj/3sf1i4tTSUWB5Q9wUuctnZMXIAzzEDg1lkBzEoxWLD cQ6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=roeckx.be Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f15si4320101oib.61.2020.01.09.14.10.50; Thu, 09 Jan 2020 14:11:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=roeckx.be Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728126AbgAIWKs (ORCPT + 99 others); Thu, 9 Jan 2020 17:10:48 -0500 Received: from excelsior.roeckx.be ([195.234.45.115]:36751 "EHLO excelsior.roeckx.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725775AbgAIWKs (ORCPT ); Thu, 9 Jan 2020 17:10:48 -0500 X-Greylist: delayed 493 seconds by postgrey-1.27 at vger.kernel.org; Thu, 09 Jan 2020 17:10:46 EST Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 3842EA8A05A9; Thu, 9 Jan 2020 22:02:31 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id EB6ED1FE0C79; Thu, 9 Jan 2020 23:02:30 +0100 (CET) Date: Thu, 9 Jan 2020 23:02:30 +0100 From: Kurt Roeckx To: "Theodore Y. Ts'o" Cc: Stephan Mueller , Andy Lutomirski , Andy Lutomirski , LKML , Linux API , Kees Cook , "Jason A. Donenfeld" , "Ahmed S. Darwish" , Lennart Poettering , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , Ext4 Developers List , linux-man Subject: Re: [PATCH v3 0/8] Rework random blocking Message-ID: <20200109220230.GA39185@roeckx.be> References: <20191226140423.GB3158@mit.edu> <4048434.Q8HajmOrkZ@tauon.chronox.de> <20191227130436.GC70060@mit.edu> <15817620.rmTN4T87Wr@tauon.chronox.de> <20191227220857.GD70060@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191227220857.GD70060@mit.edu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Dec 27, 2019 at 05:08:57PM -0500, Theodore Y. Ts'o wrote: > On Fri, Dec 27, 2019 at 10:22:23PM +0100, Stephan Mueller wrote: > > > So let's take a step back and ask the question: "Exactly what _value_ > > > do you want to provide by creating some kind of true random > > > interface?" What does this enable? What applications does this > > > really help? > > > > There are simply cryptographers who have use cases for such random numbers. > > The core use case is to seed other DRNGs and avoiding the chaining of free- > > running DRNGs. > > For this very specialized use case, what I think the kernel should > provide is maximal transparency; that is, given the DRBG direct access > to the TPM's random number generator, or direct access to the > ChaosKey, and the userspace DRBG should be able to get a list of the > various hardware RNG's, and select one, with the characterization > being done userspace, not in the kernel. One thing the NIST DRBGs have is prediction resistance, which is done by reseeding. If you chain DRBGs, you tell your parent DRBG that you want prediction resistance, so your parent will also reseed. There currently is no way to tell the kernel to reseed. This reseed option might be something that some people would like to see. If such an option is added, I expect that the kernel might block until it has gotten enough new entropy from it's entropy sources. But I don't actually see a need to add such an option. If the kernel provides a good RNG, the only reason I can see why you would like to have direct access to a hwrng is to verify that it's working correctly. That might mean that you put it in some special mode where it returns raw unprocessed values. If the device is in such a mode, it's output will not provide the same entropy per bit, and so I would expect the kernel to stop using it directly. I guess there might be people who would like to use it directly, but I think we should instead encourage them kernel RNG. > You can talk about providing tools that try to make these estimations > --- but these sorts of things would have to be done on each user's > hardware, and for most distro users, it's just not practical. I would check my own hardware if such an option was available. I think it can be useful to see if the current estimates in the kernel are conservative enough or not. But it would require that you can know what the entropy source is, like the keyboard or harddisk. > So if it's just for cryptographers, then let it all be done in > userspace, and let's not make it easy for GPG, OpenSSL, etc., to all > say, "We want TrueRandom(tm); we won't settle for less". I don't think we want that. As far as I know, the only reason for using /dev/random is that /dev/urandom returns data before it has sufficient entropy. Kurt