[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YaXrDnsE4+xSGDep@kroah.com>
Date: Tue, 30 Nov 2021 10:12:46 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Stephan Mueller <smueller@...onox.de>
Cc: Sandy Harris <sandyinchina@...il.com>,
Simo Sorce <simo@...hat.com>,
"Jason A. Donenfeld" <Jason@...c4.com>, 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>,
"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 Tue, Nov 30, 2021 at 09:56:41AM +0100, Stephan Mueller wrote:
> Am Dienstag, 30. November 2021, 08:55:53 CET schrieb Greg Kroah-Hartman:
>
> Hi Greg,
>
> > On Tue, Nov 30, 2021 at 03:32:38PM +0800, Sandy Harris wrote:
> > > 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.
> >
> > This whole "may not be" guessing game when it comes to FIPS
> > certification is a huge problem. I have heard of different vendors
> > getting different feedback and different implementations "passing" in
> > different ways that totally contradict each other. It seems that there
> > is a whole certification industry built up that you can use to try to
> > pass these tests, but those tests are different depending on the vendor
> > you use for this, making a total mess.
> >
> > So perhaps getting solid answers, and having the FIPS people actually
> > implement (or at least review) the changes and submit them (this is all
> > open for everyone to see and work on), would be the best thing as that
> > would at least let us know that this is what they require.
>
> Just as a note: I am working as FIPS tester. I am part of the NIST entropy
> working group which oversees the entropy related requirements. The LRNG's FIPS
> compliant implementation is directly based on those requirements. The LRNG was
> even reviewed by NIST personnel who mentioned that they do not see any
> contradiction to the specification. Finally, we are pursuing to get a separate
> ENT validation from NIST for the LRNG which would indicate that the LRNG meets
> all their requirements.
That's great, so you would be one of the best people to help submit
changes to the existing code to have it be compliant, instead of
replacing it entirely :)
thanks,
greg k-h
Powered by blists - more mailing lists