linux-kernel - Re: [PATCH v3 0/8] Rework random blocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191228070111.GB2519@1wt.eu>
Date:   Sat, 28 Dec 2019 08:01:11 +0100
From:   Willy Tarreau <w@....eu>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Stephan Mueller <smueller@...onox.de>,
        Andy Lutomirski <luto@...capital.net>,
        Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>
Subject: Re: [PATCH v3 0/8] Rework random blocking

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