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

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Jan 28, 2022 at 04:37:26PM +0100, Stephan Mueller wrote:
> Am Mittwoch, 26. Januar 2022, 23:49:03 CET schrieb Eric Biggers:
> 
> Hi Eric,
> 
> > On Wed, Jan 26, 2022 at 08:02:54AM +0100, Stephan Müller wrote:
> > > The current code base of the kernel crypto API random number support
> > > leaves the task to seed and reseed the DRNG to either the caller or
> > > the DRNG implementation. The code in crypto/drbg.c implements its own
> > > seeding strategy. crypto/ansi_cprng.c does not contain any seeding
> > > operation. The implementation in arch/s390/crypto/prng.c has yet
> > > another approach for seeding. Albeit the crypto_rng_reset() contains
> > > a seeding logic from get_random_bytes, there is no management of
> > > the DRNG to ensure proper reseeding or control which entropy sources
> > > are used for pulling data from.
> > 
> > ansi_cprng looks like unused code that should be removed, as does the s390
> > prng.
> > 
> > With that being the case, what is the purpose of this patchset?
> 
> I would agree that ansi_csprng could be eliminated at this stage. However, the 
> S390 DRBG code base provides access to the CPACF DRBG implemented in the IBM Z 
> processors. That implementation must be seeded from software. See the function 
> invocation of cpacf_klmd or cpacf_kmc in the prng.c file.

We should still just get rid of that, since equivalent functionality is
available in software, is better tested, and isn't performance-critical.

> 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?

> 
> The conditioning hash that is available to the entropy sources is currently 
> fixed to a SHA-256 software implementation. To support conveying more entropy 
> through the conditioning hash, I would like to contribute an extension that 
> allows the use of the kernel crypto API's set of message digest 
> implementations to be used. This would not only allow using larger message 
> digests, but also hashes other than SHA.

This doesn't need to be configurable, and shouldn't be; just choose an
appropriate hash.

> Depending on use cases, it is possible that different initial seeding 
> strategies are required to be considered for the DRNG. The initial patch set 
> provides the oversampling of entropy sources and of the initial seed string in 
> addition to the conventional approach of providing at least as much entropy as 
> the security strength of the DRNG. There is a different seeding strategy in 
> the pipeline that is considered by other cryptographers for which I would like 
> to contribute the respective patch.

It would be better to standardize on one way of doing it so that people can't
choose the wrong way.

> NUMA-awareness is another aspect that should be considered. The DRNG manager 
> is prepared to instantiate one DRNG per node. The respective handler code, 
> however, is not part of the initial code drop.

random.c is already NUMA-optimized.

> In addition to the different DRNG implementations discussed before, there is 
> the possibility to add an implementation to support atomic operations. The 
> current DRBG does not guarantee to be suitable for such use cases.

random.c already supports atomic operations.

- Eric