Message-ID: <CACXcFmntNAWYCwQ6CmH5c3pn3fXbxKh=j75GZUeLkuqi3QdS+A@mail.gmail.com>
Date:   Tue, 30 Nov 2021 15:32:38 +0800
From:   Sandy Harris <sandyinchina@...il.com>
To:     Simo Sorce <simo@...hat.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Stephan Müller <smueller@...onox.de>,
        Tso Ted <tytso@....edu>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Nicolai Stange <nstange@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Andy Lavr <andy.lavr@...il.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>,
        John Kelsey <crypto.jmk@...il.com>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Mon, Nov 22, 2021 at 11:02 PM Simo Sorce <simo@...hat.com> wrote:

> ... with my distribution hat on I
> can say that FIPS is essential for us and any design must include an
> option to be FIPS certifiable.

I think I understand Ted's objections & I'm inclined to agree with
them. See also this comment from Jon Callas:

" The NIST AES_CTR_DRBG is mostly-okay. It's got a few issues
" (see <https://eprint.iacr.org/2020/619.pdf>), but you can get
" around them. I don't like that it takes a simple concept (a good block
" cipher is a good PRP/PRF) and throws enough scaffolding around it
" to make it hard to understand. I understand the reasons .., it just
" bugs me.

That said, people do want compliance with FIPS or various other
standards. That raises a number of questions.

One is for Stephan: would you care to submit patches for the
current driver that ONLY make it FIPS (and/or European standards)
compliant? No jitter, no stuff to allow different crypto, no choice to
replace the driver, ..., just FIPS. Some of those might be good
ideas, but they would not belong in a FIPS patch.

I think that would have a much better chance of acceptance
than your patches to date.

There are also more general questions:

The FIPS requirements for a deterministic RNG include a
whole rat's nest of extras, notably various self-tests, which
Stephan's patches might deal with. Or do any of the vendors
have patches for that?

FIPS defines DRNGs using either a block cipher or a hash,
but we use a stream cipher. According to Wikipedia, several
of the *BSD distros do the same.
https://en.wikipedia.org/wiki/Salsa20#ChaCha20_adoption
This seems reasonable to me, but could we persuade NIST
to add that option? I've added John Kelsey (one of the FIPS
authors) to the cc list in hopes of that.

Failing that, the Blake hash function is based on Chacha
https://en.wikipedia.org/wiki/BLAKE_(hash_function)
Should we use that to get a more easily certified DRNG?
Would that be as fast as Chacha alone?

The FIPS also require that all the entropy inputs to the
DRNG be certified. I think we have a problem there.

I suspect that many of the random number instructions
enabled by CONFIG_ARCH_RANDOM or the hardware
RNGs enabled by CONFIG_HW_RANDOM could be
certified, but that would need to be done by the vendors
and the costs might be substantial. Are any already
certified? Is there any vendor interest?

Apart from those, the current driver gets entropy in
several places. The comments have:

 * The current exported interfaces for gathering environmental noise
 * from the devices are:
 *
 *    void add_device_randomness(const void *buf, unsigned int size);
 *     void add_input_randomness(unsigned int type, unsigned int code,
 *                                unsigned int value);
 *    void add_interrupt_randomness(int irq, int irq_flags);
 *     void add_disk_randomness(struct gendisk *disk);
 *
 * add_device_randomness() is for adding data to the random pool that
 * is likely to differ between two devices (or possibly even per boot).
 * This would be things like MAC addresses or serial numbers, ...
 *
 * add_input_randomness() uses the input layer interrupt timing, as well as
 * the event type information from the hardware.
 *
 * add_interrupt_randomness() uses the interrupt timing as random
 * inputs to the entropy pool. Using the cycle counters and the irq source
 * as inputs, it feeds the randomness roughly once a second.
 *
 * add_disk_randomness() uses what amounts to the seek time of block
 * layer request events, ... Note that high-speed solid state drives with
 * very low seek times do not make for good sources of entropy, ...

I think we should eliminate add_disk_randomness() since it does
not work well on current hardware. Also, FIPS requires that
entropy sources be independent & add_interrupt_randomness()
depends on the same disk events so these sources may not be.

A similar argument could be made for getting rid of
add_input_randomness() but that would lose the event
type information. Does that matter?

The current driver also uses other sources, at least
fast_mix(), add_timer_randomness(), random_get_entropy()
and the gcc latent entropy plugin. Could/should those be
simplified to get more easily audited or certified code?

The driver also allows input of external data which is
mixed into the pool & provides an ioctl to let a user
with root privileges change the pool's entropy estimate.
Do either of those violate the FIPS requirement that
only certified entropy sources be used? I'd be happy
to lose the ioctl (or better, all the entropy estimation
machinery) but those have been part of the system
for decades. I'd definitely want to keep the option to
use external inputs.

Powered by blists - more mailing lists