openssl/test/default-and-jitter.cnf

openssl_conf = openssl_init

# Comment out the next line to ignore configuration errors
config_diagnostics = 1

[openssl_init]
providers = provider_sect
random = random

[provider_sect]
default = default_sect

[default_sect]
activate = 1

[random]
seed=JITTER
jitter: add a new provider containing a jitter entropy source alone This entropy source can be used instead of SEED-SRC. Sample openssl.cnf configuration is provided. It is built as a separate provider, because it is likely to require less frequent updates than fips provider. The same build likely can span multiple generations of FIPS 140 standard revisions. Note that rand-instances currently chain from public/private instances to primary, prior to consuming the seed. Thus currently a unique ESV needs to be obtained, and resue of jitterentropy.a certificate is not possible as is. Separately a patch will be sent to allow for unchaining public/private RAND instances for the purpose of reusing ESV. Also I do wonder if it makes sense to create a fips variant of stock SEED-SRC entropy source, which in addition to using getrandom() also verifies that the kernel is operating in FIPS mode and thus is likely a validated entropy source. As in on Linux, check that /proc/sys/crypto/fips_enabled is set to 1, and similar checks on Windows / MacOS and so on. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/24844) 2024-07-10 22:39:01 +08:00			`openssl_conf = openssl_init`

			`# Comment out the next line to ignore configuration errors`
			`config_diagnostics = 1`

			`[openssl_init]`
			`providers = provider_sect`
			`random = random`

			`[provider_sect]`
			`default = default_sect`

			`[default_sect]`
			`activate = 1`

			`[random]`
			`seed=JITTER`