From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 962B6C2D0C8 for ; Sat, 28 Dec 2019 07:01:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 766C920838 for ; Sat, 28 Dec 2019 07:01:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726409AbfL1HBb (ORCPT ); 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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