Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Stephan Mueller <smueller@chronox.de>
To:     Eric Biggers <ebiggers@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org, simo@redhat.com,
        Nicolai Stange <nstange@suse.de>
Subject: Re: [PATCH 0/7] Common entropy source and DRNG management
Date:   Sun, 06 Feb 2022 17:02:21 +0100
Message-ID: <2092435.IRzVExRRsL@tauon.chronox.de>
In-Reply-To: <Yf30GEJi/61RNq8A@gondor.apana.org.au>
References: <2486550.t9SDvczpPo@positron.chronox.de> <YfQ7FDJqb2zhVcfp@sol.localdomain> <Yf30GEJi/61RNq8A@gondor.apana.org.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

Am Samstag, 5. Februar 2022, 04:50:48 CET schrieb Herbert Xu:

Hi Herbert,

> On Fri, Jan 28, 2022 at 10:51:00AM -0800, Eric Biggers wrote:
> > > The extraction of the entropy source and DRNG management into its own
> > > component separates out the security sensitive implementation currently
> > > found in multiple locations following the strategy found in the crypto
> > > API where each moving part is separated and encapsulated.
> > > 
> > > The current implementation of the ESDM allows an easy addition of new
> > > entropy sources which are properly encapsulated in self-contained code
> > > allowing self- contained entropy analyses to be performed for each.
> > > These entropy sources would provide their seed data completely separate
> > > from other entropy sources to the DRNG preventing any mutual
> > > entanglement and thus challenges in the entropy assessment. I have
> > > additional entropy sources already available that I would like to
> > > contribute at a later stage. These entropy sources can be enabled,
> > > disabled or its entropy rate set as needed by vendors depending on
> > > their entropy source analysis. Proper default values would be used for
> > > the common case where a vendor does not want to perform its own
> > > analysis or a distro which want to provide a common kernel binary for
> > > many users.> 
> > What is the actual point of this?  The NIST DRBGs are already seeded from
> > random.c, which is sufficient by itself but doesn't play well with
> > certifications, and from Jitterentropy which the certification side is
> > happy with.  And the NIST DRBGs are only present for certification
> > purposes anyway; all real users use random.c instead.  So what problem
> > still needs to be solved?
> Indeed.  Stephan, could you please explain exactly what additional
> seeding sources are needed over the current jitter+/dev/random sources
> (and why).  Or even better, add those seeding sources that we must have
> in your patch series so that they can be evaluated together.
> 
> As it stands this patch series seems to be adding a lot of code without
> any uses.

Thank you for the clarification. I will provide that information.
> 
> Thanks,


Ciao
Stephan