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
