Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201130151231.GA24862@lst.de> <CAHmME9p4vFGWh7+CKF4f3dw5r+ru5PVG0-vP77JowX8sPhin1g@mail.gmail.com>
 <20201130165339.GE5364@mit.edu> <CAHmME9pksS8ec17RAwCNJimt4B0xZgd3qYHUPnaT4Bj4CF7n0A@mail.gmail.com>
 <20201218132519.kj3nz7swsx7vvlr5@valinor.lan> <20201223132851.55d19271@blackhole.lan>
 <20201223151014.57caf98b@ezekiel.suse.cz> <CAHmME9ooV1HRGO4bLsNKqv1EjDsUYsM6TcMbmEL=4CejTB+1ZQ@mail.gmail.com>
 <20201223170057.7c8fd710@ezekiel.suse.cz> <20201224191953.GD22388@amd>
In-Reply-To: <20201224191953.GD22388@amd>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Fri, 8 Jan 2021 16:42:11 +0800
Message-ID: <CACXcFmknEkN7YZrG3uU7Ty35SDxxCwTSU1HcePWCa=xyuUUH+w@mail.gmail.com>
Subject: Re: drivers/char/random.c needs a (new) maintainer
To:     Pavel Machek <pavel@ucw.cz>
Cc:     Petr Tesarik <ptesarik@suse.cz>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, Torsten Duwe <duwe@lst.de>,
        Marcelo Henrique Cerri <marcelo.cerri@canonical.com>,
        "Theodore Y. Ts'o" <tytso@mit.edu>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        =?UTF-8?Q?Stephan_M=C3=BCller?= <smueller@chronox.de>,
        Willy Tarreau <w@1wt.eu>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Nicolai Stange <nstange@suse.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        "Alexander E. Patrakov" <patrakov@gmail.com>,
        "Ahmed S. Darwish" <darwish.07@gmail.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        Vito Caputo <vcaputo@pengaru.com>,
        Andreas Dilger <adilger.kernel@dilger.ca>,
        Jan Kara <jack@suse.cz>, Ray Strode <rstrode@redhat.com>,
        William Jon McCann <mccann@jhu.edu>,
        zhangjs <zachary@baishancloud.com>,
        Andy Lutomirski <luto@kernel.org>,
        Florian Weimer <fweimer@redhat.com>,
        Lennart Poettering <mzxreary@0pointer.de>,
        Peter Matthias <matthias.peter@bsi.bund.de>,
        Neil Horman <nhorman@redhat.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Julia Lawall <julia.lawall@inria.fr>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        And y Lavr <andy.lavr@gmail.com>,
        Eric Biggers <ebiggers@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>, simo@redhat.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Pavel Machek <pavel@ucw.cz> wrote:

> To play devil's advocate, does RNG subsystem need to evolve? Its task
> is to get random numbers. Does it fail at the task?
>
> Problem is, random subsystem is hard to verify, and big rewrite is
> likely to cause security problems...

Parts of the problem, though, are dead easy in many of today's
environments.

Many CPUs, e,g. Intel, have an instruction that gives random
numbers. Some systems have another hardware RNG. Some
can add one using a USB device or Denker's Turbid
(https://www.av8n.com/turbid/). Many Linux instances run on
VMs so they have an emulated HWRNG using the host's
/dev/random.

None of those is necessarily 100% trustworthy, though the
published analysis for Turbid & for (one version of) the Intel
device seem adequate to me. However, if you use any
of them to scribble over the entire 4k-bit input pool and/or
a 512-bit Salsa context during initialisation, then it seems
almost certain you'll get enough entropy to block attacks.

They are all dirt cheap so doing that, and using them
again later for incremental squirts of randomness, looks
reasonable.

In many cases you could go further. Consider a system
with an intel CPU and another HWRNG, perhaps a VM.
Get 128 bits from each source & combine them using
the 128-bit finite field multiplication from the GSM
authentication. Still cheap & it cannot be worse than
the better of the two sources. If both sources are
anywhere near reasonable, this should produce 128
bits of very high grade random material, cheaply.

I am not suggesting any of these should be used for
output, but using them for initialisation whenever
possible looks obvious to me.