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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 23 Dec 2020 15:32:55 +0100
From:   "Jason A. Donenfeld" <>
To:     Petr Tesarik <>
Cc:     Torsten Duwe <>,
        Marcelo Henrique Cerri <>,
        "Theodore Y. Ts'o" <>,
        Linus Torvalds <>,
        Stephan Müller <>,
        Willy Tarreau <>,
        Linux Crypto Mailing List <>,
        Nicolai Stange <>,
        LKML <>,
        Arnd Bergmann <>,
        "Eric W. Biederman" <>,
        "Alexander E. Patrakov" <>,
        "Ahmed S. Darwish" <>,
        Matthew Garrett <>,
        Vito Caputo <>,
        Andreas Dilger <>,
        Jan Kara <>, Ray Strode <>,
        William Jon McCann <>,
        zhangjs <>,
        Andy Lutomirski <>,
        Florian Weimer <>,
        Lennart Poettering <>,
        Peter Matthias <>,
        Neil Horman <>,
        Randy Dunlap <>,
        Julia Lawall <>,
        Dan Carpenter <>,
        And y Lavr <>,
        Eric Biggers <>,
        Ard Biesheuvel <>,
Subject: Re: drivers/char/random.c needs a (new) maintainer

On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik <> wrote:
> Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable Linux kernel.

Sorry, but just because you have a "vested interest", or a financial
interest, or because you want it does not suddenly make it a good
idea. The idea is to have good crypto, not to merely check some boxes
for the bean counters.

For example, it's very unlikely that future kernel RNGs will move to
using AES, due to the performance overhead involved on non-table-based
implementations, and the lack of availability of FPU/AES-NI in all the
contexts we need. NT's fortuna machine can use AES, because NT allows
the FPU in all contexts. We don't have that luxury (or associated
performance penalty).

I would, however, be interested in a keccak-based construction. But
just using the keccak permutation does not automatically make it
"SHA-3", so we're back at the same issue again. FIPS is simply not
interesting for our requirements.


Powered by blists - more mailing lists