Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp11442154ybl; Fri, 27 Dec 2019 14:10:31 -0800 (PST) X-Google-Smtp-Source: APXvYqwBzs+b6XSNf4fhfZuspGhtlUQD1jYjo9rajlfURHGJ5fTHp8ZRLDa6cA23eK1hUaPN9qhS X-Received: by 2002:aca:c0c5:: with SMTP id q188mr3965986oif.169.1577484631420; Fri, 27 Dec 2019 14:10:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577484631; cv=none; d=google.com; s=arc-20160816; b=XvLFm7yqRuf1I59ARZeAXfaNDtUGk9dmX7XuDmYeBKoxyq5otEri7bMjCuelzBWB0h IpUn6wWfVWaEatmyvM6B7i86hbtRBfyVa3Zqa1pyRcJ71FYwE8+0Y5gTszq+/aAjzC6f y5SBFdVGKUobgpwbWtdgIgNYCj9XP7AD01YzPzYxGGjjgE2+O5oRbkyTlcyBlP0utQh0 VvhJqcQJommkrud36+QQJa3UeH9fEfZ3xmDGKBofo0DUMCbehOcYD+Kd3tMNUdv85eUv pcPkEx1pm5/bH1X8FpvCFgs4TjNpB1lXVgv1OQgacaLqCBjnNPuggL+WQeM5RMAJmm8N rSpA== 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=gHVzxTD/iJd9ThVKSGSTvY9t86vsy8HVvCGzHno0pJg=; b=Npw5y8LrMQdNS63+iIgDZ7gCJdROuU5xoiTl6JsD6nh4P8BLt8kisuIsWUzKjmoFPZ KoyF8QHMG7XblmBM5JPGrOb26LroH0NeNP4V74dBmYwuKDNe1SgExDxnZGTjx5WDm/Sz Iqew4SjNLHMLK7x19kNc0sLmpLCGoMqYBUUQZhF2RE7EBELfSj2/CyiBI9KQ+k1FNNlR +nbn4EYQgAqjAVSuhQKzmsdHhiQpElKbIHMZSpXztx1qzrd1EFdZnR0rWzF6tmdjjf4D pUsmYFzZRR8eL4+ICNxs6n7o5FKEPqwclB20JujW3x7BDTBmIrFMlURqt0CKFJ9L7d3j h9Ww== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3si17777316oih.186.2019.12.27.14.10.13; Fri, 27 Dec 2019 14:10:31 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725957AbfL0WKM (ORCPT + 99 others); Fri, 27 Dec 2019 17:10:12 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:51298 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725306AbfL0WKL (ORCPT ); Fri, 27 Dec 2019 17:10:11 -0500 Received: from callcc.thunk.org (96-72-84-49-static.hfc.comcastbusiness.net [96.72.84.49] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBRM8vac001407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Dec 2019 17:08:59 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 75080420485; Fri, 27 Dec 2019 17:08:57 -0500 (EST) Date: Fri, 27 Dec 2019 17:08:57 -0500 From: "Theodore Y. Ts'o" To: Stephan Mueller Cc: 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: <20191227220857.GD70060@mit.edu> References: <20191226140423.GB3158@mit.edu> <4048434.Q8HajmOrkZ@tauon.chronox.de> <20191227130436.GC70060@mit.edu> <15817620.rmTN4T87Wr@tauon.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15817620.rmTN4T87Wr@tauon.chronox.de> 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 10:22:23PM +0100, Stephan Mueller wrote: > > I am unsure but it sounds like you are refuting your blocking_pool > implementation. Nothing more and nothing less than the blocking_pool, just > with a more modern and further analyzed DRNG is what was referenced as a TRNG. Yes, and that's why I am planning on taking Andy's patches to drop the blocking pool. Trying to make the claim that you can read one byte from /dev/random if and only if one byte of entropy has flowed into it.... is a mug's game, for the reasons I gave above. > Or maybe the terminology of TRNG (i.e. "true") is offending. I have no concern > to have it replaced with some other terminology. Yet, I was just taking one > well-defined term. But my point is that it *isn't* a well defined term, precisely because it's completely unclear what application programmer can expect when they try to use some hypothetical GRANDOM_TRUERANDOM flag. What does that *mean*? The kernel can't offer up any guarantees about whether or not the noise source has been appropriately characterized. All say, a GPG or OpenSSL developer can do is get the vague sense that TRUERANDOM is "better" and of course, they want the best security, so of *course* they are going to try to use it. At which point it will block, and when some other clever user (maybe a distro release engineer) puts it into an init script, then systems will stop working and users will complain to Linus. And then we'll have companies like Intel claiming that RDSEED has been very carefully characterized --- by them --- and we should *obviously* trust it, and wire up RDSEED so that TRUERANDOM will have a near infinite supply of really good entropy. And they might even be correct. But this way lies a huge mess which is fundamentally social, not technical. The claim we can make for getrandom(2) is that we do the best job that we can, and we feed in as many sources as possible and hope that at least one or more sources is not known to the attacker. One of the sources could very well be AES(NSA_KEY, SEQ++). But that still will protect us from the Chinese and Russian crypto teams. And we can hope that the NSA doesn't have access to the inter-packet arrival times on the local area network, or the radio strength as recorded from the WiFi radio, etc. etc. But note that we didn't make any claims of how many bits of entropy that we have; it helps that we are implicitly making a claim that we trust the crypto algorithms. > > 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. The kernel shouldn't be mixing various noise sources together, and it certainly shouldn't be trying to claim that it knows how many bits of entropy that it gets when is trying to play some jitter entropy game on a stupid-simple CPU architecture for IOT/Embedded user cases where everything is synchronized off of a single master oscillator, and there is no CPU instruction reordering or register renaming, etc., etc. 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. 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". We can talk about how do we provide the interfaces so that those cryptographers can get the information they need so they can get access to the raw noise sources, separated out and named, and with possibly some way that the noise source can authenticate itself to the Cryptographer's userspace library/application. But all of this should probably not be in drivers/char/random.c, and we probably need to figure out a better kernel to userspace interface than what we have with /dev/hwrng. - Ted