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

[Stephan Mueller <smueller@chronox.de>]

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.

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.

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.

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.

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.

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.

Ciao
Stephan