Re: [PATCH 0/7] Common entropy source and DRNG management

[Stephan Mueller <smueller@chronox.de>]

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