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

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 22. November 2021, 22:06:55 CET schrieb Jeffrey Walton:

Hi Jeffrey,

> On Mon, Nov 22, 2021 at 10:10 AM Simo Sorce <simo@redhat.com> wrote:
> > On Mon, 2021-11-22 at 07:55 +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Nov 22, 2021 at 07:42:02AM +0100, Stephan Mueller wrote:
> > > > ...
> > > > I will leave the representatives from the distros to chime in and
> > > > point to
> > > > these patches.
> > > 
> > > Then why not work with the distros to get these changes merged into the
> > > kernel tree?  They know that keeping things out-of-the-tree costs them
> > > time and money, so why are they keeping them there?
> > 
> > I can speak for my distro.
> > We have not proposed them because they are hacks, we know they are
> > hacks, and we know they are not the long term solution.
> > Yet we have no better way (in our products, today) so far to deal with
> > these issues because what is needed is an effort like LRNG (does not
> > have to be this specific implementation), because hacks will not cut it
> > in the long term.
> 
> Kernel support for FIPS validated crypto would be very useful, IMHO.
> 
> Currently most folks I know and consult with use CentOS because CentOS
> is free and includes the FIPS canister for OpenSSL. Several folks I
> know and consult with don't have a solution because they use Debian
> derivatives, like Ubuntu. They use Ubuntu because Ubuntu offers the
> image processing packages they need out of the box.
> 
> Moving the validated crypto into the kernel would be useful since all
> distros can provide it without the need for one-off patches.
> 
> What I am less clear about.... NIST is only one standard body, and not
> everyone trusts the US. There are other bodies that should probably be
> represented, like KISA. So the big question becomes, how does the
> kernel offer "approved" crypto for different consumers? (where
> "approved" means blessed by some agency like NIST or KISA).

IMHO that is where the flexibility of the LRNG comes in. I am currently in 
discussion with the German BSI on their requirements and these requirements 
can be covered by a few extra lines since it only affects a different initial 
seeding of the DRNG.

In any case, the LRNG supports other approaches by:

- select one or more entropy sources (or provide one from external) that are 
considered appropriate

- if needed, adjust the initial seeding operation

- if needed, adjust the crypto primitives that are in use.

Ciao
Stephan
> 
> Jeff


Ciao
Stephan