linux-kernel - Re: [PATCH v43 01/15] Linux Random Number Generator

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]

Date:   Thu, 2 Dec 2021 08:12:35 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Jeffrey Walton <noloader@...il.com>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        Simo Sorce <simo@...hat.com>,
        Stephan Mueller <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>,
        "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>,
        Eric Biggers <ebiggers@...nel.org>,
        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>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Wed, Dec 01, 2021 at 07:24:43PM -0500, Jeffrey Walton wrote:
> On Wed, Dec 1, 2021 at 1:25 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
> >
> > On Wed, Dec 1, 2021 at 12:19 PM Simo Sorce <simo@...hat.com> wrote:
> > > that much it is, and it is a required one. However having worked a lot
> > > on this I can tell you there is actually real cryptographic value in
> > > the requirements FIPS introduced over the years
> > > Well I think most of the requirements are sane practices, hopefully
> > > controversial stuff will be minimal.
> > > I happen to think quite a few of the requirements are actually good
> > > ideas to implement to improve the guarantees of randomness
> >
> > If you think there are good ways to improve the RNG, of course send
> > patches for this, justifying why, taking into account recent research
> > into the topic you wish to patch, etc. Don't write, "because FIPS";
> > instead argue rationale for each patch. And if you _do_ feel the need
> > to appeal to authority, perhaps links to the various eprint papers you
> > consulted would be worthwhile. Preferably you're able to do this in a
> > small, incremental way, with small standalone patchsets, instead of
> > gigantic series.
> 
> I may be parsing things incorrectly, but you seem to be rejecting the
> NIST requirements, and then positioning your personal opinion as
> superior. It sounds like one authority is being replaced by another.
> Perhaps I am missing something.
> 
> I am also guessing you've never read the relevant NIST documents. The
> documents state the security goals and provide the steps to achieve
> them in an implementation.

Ok, I think this thread has gone on long enough without any real
patches.

Please, if you want to support NIST, or any other type of thing, submit
patches that implement what you think will help achieve this.  Absent of
that, we have no idea what NIST or any other random document aims to
require or wish.

thanks,

greg k-h