Date:   Mon, 10 Jan 2022 12:07:51 -0300
From:   Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
To:     Theodore Ts'o <tytso@mit.edu>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Simo Sorce <simo@redhat.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jeffrey Walton <noloader@gmail.com>,
        Stephan Mueller <smueller@chronox.de>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Willy Tarreau <w@1wt.eu>, 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>,
        Eric Biggers <ebiggers@kernel.org>,
        Neil Horman <nhorman@redhat.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Julia Lawall <julia.lawall@inria.fr>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Andy Lavr <andy.lavr@gmail.com>,
        Petr Tesarik <ptesarik@suse.cz>,
        John Haxby <john.haxby@oracle.com>,
        Alexander Lobakin <alobakin@mailbox.org>,
        Jirka Hladky <jhladky@redhat.com>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator
Message-ID: <20220110150751.eyragx5tk7scd5p4@valinor>
References: <ac123d96b31f4a51b167b4e85a205f31a6c97876.camel@redhat.com>
 <YaZHKHjomEivul6U@kroah.com>
 <YaZqVxI1C8RByq+w@gmail.com>
 <CAHmME9p60Ve5XJTVcmGvSpUkg_hRp_i0rGG0R9VhuwLs0o_nXQ@mail.gmail.com>
 <f4a4c9a6a06b6ab00dde24721715abaeca184a0d.camel@redhat.com>
 <CAHmME9qP9eYfPH+8eRvpx_tW8iAtDc-byVMvh4tFL_cABdsiOA@mail.gmail.com>
 <20211210014337.xmin2lu5rhhe3b3t@valinor>
 <20220110132349.siplwka7yhe2tmwc@valinor>
 <CAHmME9oSK5sVVhMewm-oVvn=twP4yyYnLY0OVebYZ0sy1mQAyA@mail.gmail.com>
 <YdxCsI3atPILABYe@mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="yrkvaum5odjlkfrt"
Content-Disposition: inline
In-Reply-To: <YdxCsI3atPILABYe@mit.edu>
Precedence: bulk


--yrkvaum5odjlkfrt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 10, 2022 at 09:29:04AM -0500, Theodore Ts'o wrote:
> On Mon, Jan 10, 2022 at 03:11:46PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Jan 10, 2022 at 2:24 PM Marcelo Henrique Cerri
> > <marcelo.cerri@canonical.com> wrote:
> > > Hoping that might help with the discussion and to explain why I do
> > > consider those solutions a "hack", that's the patch we've been using
> > > so far to achieve SP 800-90B compliance:
> > >
> > > https://kernel.ubuntu.com/~mhcerri/0001-UBUNTU-SAUCE-random-Use-Crypt=
o-API-DRBG-for-urandom-.patch
> >=20
> > Thanks for sending this in response to my request for it in our private=
 thread.

No problem. And sorry for the delay.

> >=20
> > Just to confirm, this little patch here gives you FIPS certification?

It does because it basically replaces everything in random.c (for
urandom in this case) with the Crypto API DRBG, which is
compliant. Although it might be wiser to replace both urandom and
random in this case.

>=20
> There might be some FIPS certification labs that might be willing to
> be taken in by the jitterentropy story, but when I've had private
> communications from people who are familiar with the Intel
> microarchitecture saying that jitterentropy is mostly "security by
> obscurity", I'd be strongly opposed to replacing the current scheme
> with something which is purely jitteretropy.
>=20
> Perhaps an build-time option where one of the seeds into the CRNG is
> "jitterentropy", but we keep everything else.  That way, jitterentropy
> can still be TSA-style "security theatre", but we're not utterly
> dependant on the "the CPU microarchitecture is SOOOOOOO complicated,
> it *must* be unpredictable".
>

Hi, Theodore.

I might be missing something, but the Crypto API DRBG is seeded by
jitterentropy_rng and by get_random_bytes(), their outputs are both
concatenated and used as the seed. So I don't think that should be a
concern, right?


> 						- Ted

--=20
Regards,
Marcelo


--yrkvaum5odjlkfrt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEExJjLjAfVL0XbfEr56e82LoessAkFAmHcS8cACgkQ6e82Loes
sAkzfQv/YFKX+P7lMLHqRDZj2C8ENBjvbx6HOZyNGL9QEucfEHEAlRjjErgxFObs
H0SfkUmIEgg1JGJPCTFrD4Wge4LsU2ZY4seQvl1GM1zpC90icUY//Y1mc+rjpW/A
svYUwA7o7J0+nsZqreMyAgqF3inu6GujSywYHzP71Fjaq61Mu5+5jY//07LpYU4x
uPo2uKiG1d3GjFKWD7QHzgudF+X0/SaVA5NGEDDR0z6G7QS5R2HvDoj8sulCcyr1
nLSkiYQNUAivYPzlgwF/x/ezLdPHvrRWpGJnWkDrPlGfz1cdamdr7z2CgmbX8xZN
q8XUIOrH2d08S4HYh3Z6j3u3E8OQMxQ4vBZKdKs980h65h4AI5gunacKPBBELzED
CCuYycmZlL8BmYW6w1e1Ewnlkfb1xkFW/dElps6RJuJJGbipKCHx9kOgyc6kc6OC
rfuLDaIIb1LJvCuGPsBNGuSMu7wl94f/ueUMTxcFumaQb7GIwzG3/tmKVm2PeAOG
uXF8c05f
=Jjuy
-----END PGP SIGNATURE-----

--yrkvaum5odjlkfrt--