Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp11813333ybl; Fri, 27 Dec 2019 23:02:24 -0800 (PST) X-Google-Smtp-Source: APXvYqzrmrG6WWVEfzX635sGPJxFEjn12qm0VmsGDwQESxiSp5AB5VDfwFJEhnX9iaRIq4jyUHvd X-Received: by 2002:a9d:133:: with SMTP id 48mr59143933otu.15.1577516544522; Fri, 27 Dec 2019 23:02:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577516544; cv=none; d=google.com; s=arc-20160816; b=c+61McpejQWZ7cKs2jiyVxZDh2lkwIWkU9mQlFZBegeAmrfSMLn2gHF8qgvJew2ScX H4MkvfjTe9AidmbXpNO208VgbjGzjmM2+PNBoi3K2Dd/jTf7UM/AeRx+0icTUO+OBY9S QPEsVEc0V2yJ5syYMUEkUJWn3ylcdUJMA3n0vAIWYS8+PQTBVL1muFxSBzQwNeVHByJ9 6mMNlpWWXOrzF7GQj5Y+TmtGuD6azRB/6RYuEnhyhpng5LCFoksKGoz1eIYCHdeo+VHz EQ0lW0Z3GRzRPDEAgmBUiksluk2pqp+SGqFV+NDDPVtgKq0OYeEI7QTW6MqCyF2tg0e/ 6mvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Clca5lIzH75GT3nLZ3dHK6QYTK1TQRZ+vKea3aHQ3Is=; b=ROp+0IW7WEahEWFkAXphVcwdsSkBSZ7pOorYrgFh9I0LuCTj44AayeY+78ijC9liID vuFPnmJ1Zm+R21Mr/hAG2749jfPZFVXItqonBnJErK8gWMN+deDTrfwnBJq0+nLQm7V/ +5O7WLbVCFuQLgn6FXjBKUh6at4dIXedh0GmjqjVARpuj7zOAKvD6ZcQbnkW6AhHwNFF e8o5hyamBgSHbBGqXCyJq0xlDCNdu/ssPHuh4SL/vzociiyvngJ5Xs1TeFJP7BHtlNSO kJW8rtFEFIRjE0X4Xmm+5XEg3t/Dv/ItzWOXwkw2vU3tcj9Em/azuUCfX+3H2TUWRCMV Aygw== 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 r1si17801974otk.251.2019.12.27.23.01.34; Fri, 27 Dec 2019 23:02:24 -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 S1726045AbfL1HBb (ORCPT + 99 others); Sat, 28 Dec 2019 02:01:31 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:29841 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725857AbfL1HBb (ORCPT ); Sat, 28 Dec 2019 02:01:31 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id xBS71BFU002595; Sat, 28 Dec 2019 08:01:11 +0100 Date: Sat, 28 Dec 2019 08:01:11 +0100 From: Willy Tarreau 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 , Matthew Garrett , Ext4 Developers List , linux-man Subject: Re: [PATCH v3 0/8] Rework random blocking Message-ID: <20191228070111.GB2519@1wt.eu> 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> User-Agent: Mutt/1.6.1 (2016-04-27) 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: > > 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*? I've also seen this term used and abused too many times and this bothers me because the expectations around it are the cause of the current situation. Randomness doesn't exist by itself. It's what characterizes the unpredictable nature of something. I.e. our inability to model it and guess what will happen based on what we know. 200 years ago we'd have considered the weather as a true random source. Now we have super computers making this moot. In the current state of art we consider that cesium decay or tunnel noise are unpredictable and excellent random sources, until one day we figure that magnetic fields, temperature or gamma rays strongly affect them. So in practice we should only talk about the complexity of the model we rely on. The more complex it is (i.e. the most independent variables it relies on), the less predictable it is and the more random it is. Jitter entropy and RAM contents are good examples of this: they may be highly unpredictable on some platforms and almost constant on others. And for sure, software cannot fix this, it can at best make the output *look* like it's unpredictable. Once someone can model all variables of the environment this is not true random anymore. That's why the best we can do is to combine as many sources as possible hoping that nobody can model enough of them, and produce an output which never ever reveals these sources' internal states. *This* is what software can and must do. And once the initial entropy is hidden enough and there is enough of it, there's no reason for it to ever get depleted if these initial bits cannot be guessed nor brute-forced. And quite frankly I'd rather just speak about the diversity of sources than "true" randomness. Just asking a user to press 10 random keys and to enter a random word for some operations can break many assumptions an attacker could have about the environment, by just adding one extra, less controllable, source. Just my two cents, Willy