| Message ID | 2486550.t9SDvczpPo@positron.chronox.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Common entropy source and DRNG management | expand |
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? - Eric
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
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
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. Thanks,
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
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. The task of seeding and reseeding a DRNG including the controlling of the state of the entropy sources is security sensitive as the strength of the data obtained from the DRNG rests in large parts on the proper seeding. In addition, various aspects need to be considered when (re)seeding a DRNG. This gap is filled with the Entropy Source and DRNG Manager (ESDM) proposed by this patch set. The ESDM consists of two managers: the manager for the DRNG(s) and manager for the entropy sources. The DRNG manager ensures that DRNGs are properly seeded before random numbers are obtained from them. Similarly, the entropy source manager ensures that the available entropy sources are properly initialized if needed, and that data is obtained with an appropriately considered entropy rate. Both, the DRNG and entropy source managers offer a pluggable interface allowing to use different DRNG implementations as well as various entropy sources. Each provided entropy source may be enabled during compile time. The ESDM therefore provides flexibility in the future to extend the set of entropy sources or the supported DRNGs to the required algorithms. The patch set consists of the following changes: - Patch 1 removes the seeding and reseeding logic from the DRBG transforming it into a pure deterministic implementation. - Patch 2 removes the special AF_ALG interface used to test the DRBG implementation which requires bypassing of the DRBG automated seeding from entropy sources. With patch 1 this is not needed any more. - Patch 3 adds the ESDM with its DRNG and entropy source managers. It contains the support to use the kernel crypto API's DRNG implementations. - Patches 4 and 5 use the existing Jitter RNG as an entropy source for the ESDM. - Patch 6 provides the glue code to use the get_random_bytes function as entropy source to the ESDM. - Patch 7 adds the ESDM interface to register it with the kernel crypto API RNG framework as "stdrng" with the highest priority. This way, the ESDM is used per default when using the call crypto_get_default_rng(). With this patch series, callers to the kernel crypto API would not experience any difference. When using the RNG framework, the function crypto_get_default_rng is commonly used. Instead of providing the DRBG implementation, the ESDM is used which returns random numbers from a properly seeded DRBG. Stephan Mueller (7): crypto: DRBG - remove internal reseeding operation crypto: AF_ALG - remove ALG_SET_DRBG_ENTROPY interface crypto: Entropy Source and DRNG Manager crypto: move Jitter RNG header include dir crypto: ESDM - add Jitter RNG entropy source crypto: ESDM - add Kernel RNG entropy source crypto: ESDM - add kernel crypto API RNG interface crypto/Kconfig | 11 +- crypto/Makefile | 1 + crypto/af_alg.c | 7 - crypto/algif_rng.c | 74 +- crypto/drbg.c | 640 ++++------------- crypto/esdm/Kconfig | 166 +++++ crypto/esdm/Makefile | 15 + crypto/esdm/esdm_definitions.h | 141 ++++ crypto/esdm/esdm_drng_kcapi.c | 202 ++++++ crypto/esdm/esdm_drng_kcapi.h | 13 + crypto/esdm/esdm_drng_mgr.c | 398 +++++++++++ crypto/esdm/esdm_drng_mgr.h | 85 +++ crypto/esdm/esdm_es_aux.c | 332 +++++++++ crypto/esdm/esdm_es_aux.h | 44 ++ crypto/esdm/esdm_es_jent.c | 128 ++++ crypto/esdm/esdm_es_jent.h | 17 + crypto/esdm/esdm_es_krng.c | 120 ++++ crypto/esdm/esdm_es_krng.h | 17 + crypto/esdm/esdm_es_mgr.c | 372 ++++++++++ crypto/esdm/esdm_es_mgr.h | 46 ++ crypto/esdm/esdm_es_mgr_cb.h | 73 ++ crypto/esdm/esdm_interface_kcapi.c | 91 +++ crypto/esdm/esdm_sha.h | 14 + crypto/esdm/esdm_sha256.c | 72 ++ crypto/jitterentropy-kcapi.c | 3 +- crypto/jitterentropy.c | 2 +- crypto/testmgr.c | 104 +-- crypto/testmgr.h | 641 +----------------- include/crypto/drbg.h | 84 --- include/crypto/esdm.h | 115 ++++ include/crypto/if_alg.h | 1 - .../crypto/internal}/jitterentropy.h | 0 include/crypto/internal/rng.h | 6 - include/crypto/rng.h | 4 - include/uapi/linux/if_alg.h | 2 +- 35 files changed, 2615 insertions(+), 1426 deletions(-) create mode 100644 crypto/esdm/Kconfig create mode 100644 crypto/esdm/Makefile create mode 100644 crypto/esdm/esdm_definitions.h create mode 100644 crypto/esdm/esdm_drng_kcapi.c create mode 100644 crypto/esdm/esdm_drng_kcapi.h create mode 100644 crypto/esdm/esdm_drng_mgr.c create mode 100644 crypto/esdm/esdm_drng_mgr.h create mode 100644 crypto/esdm/esdm_es_aux.c create mode 100644 crypto/esdm/esdm_es_aux.h create mode 100644 crypto/esdm/esdm_es_jent.c create mode 100644 crypto/esdm/esdm_es_jent.h create mode 100644 crypto/esdm/esdm_es_krng.c create mode 100644 crypto/esdm/esdm_es_krng.h create mode 100644 crypto/esdm/esdm_es_mgr.c create mode 100644 crypto/esdm/esdm_es_mgr.h create mode 100644 crypto/esdm/esdm_es_mgr_cb.h create mode 100644 crypto/esdm/esdm_interface_kcapi.c create mode 100644 crypto/esdm/esdm_sha.h create mode 100644 crypto/esdm/esdm_sha256.c create mode 100644 include/crypto/esdm.h rename {crypto => include/crypto/internal}/jitterentropy.h (100%)