kernel/linux.git/crypto/drbg.c, branch v6.12.80

crypto: drbg - Remove SHA1 from drbg

2023-11-17T11:16:29+00:00

SP800-90C 3rd draft states that SHA-1 will be removed from all specifications, including drbg by end of 2030. Given kernels built today will be operating past that date, start complying with upcoming requirements. No functional change, as SHA-256 / SHA-512 based DRBG have always been the preferred ones. Signed-off-by: Dimitri John Ledkov Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - ensure drbg hmac sha512 is used in FIPS selftests

2023-11-17T11:16:29+00:00

Update code comment, self test & healthcheck to use HMAC SHA512, instead of HMAC SHA256. These changes are in dead-code, or FIPS enabled code-paths only and have not effect on usual kernel builds. On systems booting in FIPS mode that has the effect of switch sanity selftest to HMAC sha512 based (which has been the default DRBG). This patch updates code from 9b7b94683a ("crypto: DRBG - switch to HMAC SHA512 DRBG as default DRBG"), but is not interesting to cherry-pick for stable updates, because it doesn't affect regular builds, nor has any tangible effect on FIPS certifcation. Signed-off-by: Dimitri John Ledkov Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - update FIPS CTR self-checks to aes256

2023-11-17T11:16:29+00:00

When originally drbg was introduced FIPS self-checks for all types but CTR were using the most preferred parameters for each type of DRBG. Update CTR self-check to use aes256. This patch updates code from 541af946fe ("crypto: drbg - SP800-90A Deterministic Random Bit Generator"), but is not interesting to cherry-pick for stable updates, because it doesn't affect regular builds, nor has any tangible effect on FIPS certifcation. Signed-off-by: Dimitri John Ledkov Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - ensure most preferred type is FIPS health checked

2023-11-17T11:16:29+00:00

drbg supports multiple types of drbg, and multiple parameters of each. Health check sanity only checks one drbg of a single type. One can enable all three types of drbg. And instead of checking the most preferred algorithm (last one wins), it is currently checking first one instead. Update ifdef to ensure that healthcheck prefers HMAC, over HASH, over CTR, last one wins, like all other code and functions. This patch updates code from 541af946fe ("crypto: drbg - SP800-90A Deterministic Random Bit Generator"), but is not interesting to cherry-pick for stable updates, because it doesn't affect regular builds, nor has any tangible effect on FIPS certifcation. Signed-off-by: Dimitri John Ledkov Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - stop checking crypto_shash_alignmask

2023-10-27T10:04:25+00:00

Now that the shash algorithm type does not support nonzero alignmasks, crypto_shash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_shash_alignmask() in drbg. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: drbg - Only fail when jent is unavailable in FIPS mode

2023-04-06T08:18:53+00:00

When jent initialisation fails for any reason other than ENOENT, the entire drbg fails to initialise, even when we're not in FIPS mode. This is wrong because we can still use the kernel RNG when we're not in FIPS mode. Change it so that it only fails when we are in FIPS mode. Fixes: 57225e679788 ("crypto: drbg - Use callback API for random readiness") Signed-off-by: Herbert Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - remove unnecessary (void*) conversions

2022-08-19T10:39:36+00:00

remove unnecessary void* type casting v2: Turn assignments less than 75 characters into one line. Signed-off-by: Dong Chuanjian Signed-off-by: Herbert Xu

crypto: drbg - ignore jitterentropy errors if not in FIPS mode

2021-12-11T05:48:06+00:00

A subsequent patch will make the jitterentropy RNG to unconditionally report health test errors back to callers, independent of whether fips_enabled is set or not. The DRBG needs access to a functional jitterentropy instance only in FIPS mode (because it's the only SP800-90B compliant entropy source as it currently stands). Thus, it is perfectly fine for the DRBGs to obtain entropy from the jitterentropy source only on a best effort basis if fips_enabled is off. Make the DRBGs to ignore jitterentropy failures if fips_enabled is not set. Signed-off-by: Nicolai Stange Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: drbg - reseed 'nopr' drbgs periodically from get_random_bytes()

2021-11-26T05:16:50+00:00

In contrast to the fully prediction resistant 'pr' DRBGs, the 'nopr' variants get seeded once at boot and reseeded only rarely thereafter, namely only after 2^20 requests have been served each. AFAICT, this reseeding based on the number of requests served is primarily motivated by information theoretic considerations, c.f. NIST SP800-90Ar1, sec. 8.6.8 ("Reseeding"). However, given the relatively large seed lifetime of 2^20 requests, the 'nopr' DRBGs can hardly be considered to provide any prediction resistance whatsoever, i.e. to protect against threats like side channel leaks of the internal DRBG state (think e.g. leaked VM snapshots). This is expected and completely in line with the 'nopr' naming, but as e.g. the "drbg_nopr_hmac_sha512" implementation is potentially being used for providing the "stdrng" and thus, the crypto_default_rng serving the in-kernel crypto, it would certainly be desirable to achieve at least the same level of prediction resistance as get_random_bytes() does. Note that the chacha20 rngs underlying get_random_bytes() get reseeded every CRNG_RESEED_INTERVAL == 5min: the secondary, per-NUMA node rngs from the primary one and the primary rng in turn from the entropy pool, provided sufficient entropy is available. The 'nopr' DRBGs do draw randomness from get_random_bytes() for their initial seed already, so making them to reseed themselves periodically from get_random_bytes() in order to let them benefit from the latter's prediction resistance is not such a big change conceptually. In principle, it would have been also possible to make the 'nopr' DRBGs to periodically invoke a full reseeding operation, i.e. to also consider the jitterentropy source (if enabled) in addition to get_random_bytes() for the seed value. However, get_random_bytes() is relatively lightweight as compared to the jitterentropy generation process and thus, even though the 'nopr' reseeding is supposed to get invoked infrequently, it's IMO still worthwhile to avoid occasional latency spikes for drbg_generate() and stick to get_random_bytes() only. As an additional remark, note that drawing randomness from the non-SP800-90B-conforming get_random_bytes() only won't adversely affect SP800-90A conformance either: the very same is being done during boot via drbg_seed_from_random() already once rng_is_initialized() flips to true and it follows that if the DRBG implementation does conform to SP800-90A now, it will continue to do so. Make the 'nopr' DRBGs to reseed themselves periodically from get_random_bytes() every CRNG_RESEED_INTERVAL == 5min. More specifically, introduce a new member ->last_seed_time to struct drbg_state for recording in units of jiffies when the last seeding operation had taken place. Make __drbg_seed() maintain it and let drbg_generate() invoke a reseed from get_random_bytes() via drbg_seed_from_random() if more than 5min have passed by since the last seeding operation. Be careful to not to reseed if in testing mode though, or otherwise the drbg related tests in crypto/testmgr.c would fail to reproduce the expected output. In order to keep the formatting clean in drbg_generate() wrap the logic for deciding whether or not a reseed is due in a new helper, drbg_nopr_reseed_interval_elapsed(). Signed-off-by: Nicolai Stange Reviewed-by: Stephan Müller Signed-off-by: Herbert Xu

crypto: drbg - make drbg_prepare_hrng() handle jent instantiation errors

2021-11-26T05:16:50+00:00

Now that drbg_prepare_hrng() doesn't do anything but to instantiate a jitterentropy crypto_rng instance, it looks a little odd to have the related error handling at its only caller, drbg_instantiate(). Move the handling of jitterentropy allocation failures from drbg_instantiate() close to the allocation itself in drbg_prepare_hrng(). There is no change in behaviour. Signed-off-by: Nicolai Stange Reviewed-by: Stephan Müller Signed-off-by: Herbert Xu