From 9628e03476f750d36af330175c6904156f944f2b Mon Sep 17 00:00:00 2001 From: Fabrice Benhamouda Date: Thu, 25 Apr 2024 14:33:21 -0400 Subject: [PATCH 1/4] Remove comments about overread for entropy generation AWS-LC does not overread entropy sources in FIPS mode. This commit is to clarify this and remove/rephrase comments mentioning overread. --- crypto/fipsmodule/FIPS.md | 4 +--- crypto/fipsmodule/rand/rand.c | 5 +++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/crypto/fipsmodule/FIPS.md b/crypto/fipsmodule/FIPS.md index 4d288ad6b2..91b9a001f4 100644 --- a/crypto/fipsmodule/FIPS.md +++ b/crypto/fipsmodule/FIPS.md @@ -40,7 +40,7 @@ The DRBG state is kept in a thread-local structure and is seeded using the confi The CTR-DRBG is reseeded every 4096 calls to `RAND_bytes`. Thus the process will randomly crash about every 2¹³⁵ calls. -The FIPS PRNGs allow “additional input” to be fed into a given call. We use this feature to be as robust as possible to state duplication from process forks and VM copies: for every call we read 32 bytes of “additional data” from the entropy source (without overread) which means that cloned states will diverge at the next call to `RAND_bytes`. This is called “prediction resistance” by FIPS, but we do *not* claim this property in a FIPS context because we don't implement it the way they want. +The FIPS PRNGs allow “additional input” to be fed into a given call. We use this feature to be as robust as possible to state duplication from process forks and VM copies: for every call we read 32 bytes of “additional data” from the entropy source which means that cloned states will diverge at the next call to `RAND_bytes`. This is called “prediction resistance” by FIPS, but we do *not* claim this property in a FIPS context because we don't implement it the way they want. There is a second interface to the RNG which allows the caller to supply bytes that will be XORed into the generated additional data (`RAND_bytes_with_additional_data`). This is used in the ECDSA code to include the message and private key in the generation of *k*, the ECDSA nonce. This allows ECDSA to be robust to entropy failures while still following the FIPS rules. @@ -50,8 +50,6 @@ FIPS requires that RNG state be zeroed when the process exits. In order to imple By default, entropy is sourced using a "Passive" method where the specific entropy source depends on the OE. Seeding and reseeding material for the DRBG is sourced from the specific entropy source. -In FIPS mode, each of the entropy sources is subject to a 10× overread. That is, when *n* bytes of entropy are needed, *10n* bytes will be read from the entropy source and XORed down to *n* bytes. - ### Modify entropy source - not recommended Modifying the entropy source can invalidate your validation status. Changing the entropy is **not** recommended. diff --git a/crypto/fipsmodule/rand/rand.c b/crypto/fipsmodule/rand/rand.c index 346cbeb965..5582d3fe92 100644 --- a/crypto/fipsmodule/rand/rand.c +++ b/crypto/fipsmodule/rand/rand.c @@ -364,8 +364,9 @@ static void rand_get_seed(struct rand_thread_state *state, static void rand_get_seed(struct rand_thread_state *state, uint8_t seed[CTR_DRBG_ENTROPY_LEN], int *out_want_additional_input) { - // If not in FIPS mode, we don't overread from the system entropy source and - // we don't depend only on the hardware RDRAND. + // If not in FIPS mode, we use the system entropy source. + // We don't source the entropy directly from the CPU. + // Therefore, |*out_want_additonal_input| is set to zero. CRYPTO_sysrand_for_seed(seed, CTR_DRBG_ENTROPY_LEN); *out_want_additional_input = 0; } From 7962f75d9e836cd5ad84beed3385add9157c8a30 Mon Sep 17 00:00:00 2001 From: Fabrice Benhamouda <1146316+fabrice102@users.noreply.github.com> Date: Thu, 25 Apr 2024 14:50:09 -0400 Subject: [PATCH 2/4] Update crypto/fipsmodule/FIPS.md Clarification --- crypto/fipsmodule/FIPS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/fipsmodule/FIPS.md b/crypto/fipsmodule/FIPS.md index 91b9a001f4..c9bcbeccf8 100644 --- a/crypto/fipsmodule/FIPS.md +++ b/crypto/fipsmodule/FIPS.md @@ -40,7 +40,7 @@ The DRBG state is kept in a thread-local structure and is seeded using the confi The CTR-DRBG is reseeded every 4096 calls to `RAND_bytes`. Thus the process will randomly crash about every 2¹³⁵ calls. -The FIPS PRNGs allow “additional input” to be fed into a given call. We use this feature to be as robust as possible to state duplication from process forks and VM copies: for every call we read 32 bytes of “additional data” from the entropy source which means that cloned states will diverge at the next call to `RAND_bytes`. This is called “prediction resistance” by FIPS, but we do *not* claim this property in a FIPS context because we don't implement it the way they want. +The FIPS PRNGs allow “additional input” to be fed into a given call. We use this feature to be as robust as possible to state duplication from process forks and VM copies: on Intel CPUs with RDRAND, for every call we read 32 bytes of “additional data” from RDRAND, which means that cloned states will diverge at the next call to `RAND_bytes`. This is called “prediction resistance” by FIPS, but we do *not* claim this property in a FIPS context because we don't implement it the way they want. There is a second interface to the RNG which allows the caller to supply bytes that will be XORed into the generated additional data (`RAND_bytes_with_additional_data`). This is used in the ECDSA code to include the message and private key in the generation of *k*, the ECDSA nonce. This allows ECDSA to be robust to entropy failures while still following the FIPS rules. From ef3e86f571551670239d93d56610b2997dded147 Mon Sep 17 00:00:00 2001 From: Fabrice Benhamouda Date: Thu, 25 Apr 2024 17:01:14 -0400 Subject: [PATCH 3/4] Clarifying that the CPU Jitter entropy performs a 3x oversampling --- crypto/fipsmodule/FIPS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/fipsmodule/FIPS.md b/crypto/fipsmodule/FIPS.md index c9bcbeccf8..486075e9f4 100644 --- a/crypto/fipsmodule/FIPS.md +++ b/crypto/fipsmodule/FIPS.md @@ -50,6 +50,8 @@ FIPS requires that RNG state be zeroed when the process exits. In order to imple By default, entropy is sourced using a "Passive" method where the specific entropy source depends on the OE. Seeding and reseeding material for the DRBG is sourced from the specific entropy source. +In FIPS mode, when the CPU Jitter entropy source is used, we do a 3x oversampling (the CPU Jitter default setting). Note that the CPU Jitter entropy source is not the default entropy source (see subsection below). + ### Modify entropy source - not recommended Modifying the entropy source can invalidate your validation status. Changing the entropy is **not** recommended. From 073931b8e4cba0127964dbec9c1042f2aa6736bc Mon Sep 17 00:00:00 2001 From: Fabrice Benhamouda <1146316+fabrice102@users.noreply.github.com> Date: Thu, 25 Apr 2024 17:07:11 -0400 Subject: [PATCH 4/4] Update crypto/fipsmodule/FIPS.md Co-authored-by: Nevine Ebeid <66388554+nebeid@users.noreply.github.com> --- crypto/fipsmodule/FIPS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/fipsmodule/FIPS.md b/crypto/fipsmodule/FIPS.md index 486075e9f4..b514b1a717 100644 --- a/crypto/fipsmodule/FIPS.md +++ b/crypto/fipsmodule/FIPS.md @@ -50,7 +50,7 @@ FIPS requires that RNG state be zeroed when the process exits. In order to imple By default, entropy is sourced using a "Passive" method where the specific entropy source depends on the OE. Seeding and reseeding material for the DRBG is sourced from the specific entropy source. -In FIPS mode, when the CPU Jitter entropy source is used, we do a 3x oversampling (the CPU Jitter default setting). Note that the CPU Jitter entropy source is not the default entropy source (see subsection below). +In FIPS mode, when the CPU Jitter entropy source is used, we do a 3x oversampling (the CPU Jitter default setting). Note that the CPU Jitter is not the default entropy source (see subsection below). ### Modify entropy source - not recommended