Skip to content

Commit

Permalink
Remove comments about overread for entropy generation (#1551)
Browse files Browse the repository at this point in the history
AWS-LC does not overread default entropy sources in FIPS mode. This commit is to
clarify this and remove/rephrase comments mentioning overread.
  • Loading branch information
fabrice102 committed Apr 30, 2024
1 parent f8a575f commit a66c66e
Show file tree
Hide file tree
Showing 2 changed files with 5 additions and 4 deletions.
4 changes: 2 additions & 2 deletions crypto/fipsmodule/FIPS.md
Original file line number Diff line number Diff line change
Expand Up @@ -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: 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.

Expand All @@ -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, 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.
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

Expand Down
5 changes: 3 additions & 2 deletions crypto/fipsmodule/rand/rand.c
Original file line number Diff line number Diff line change
Expand Up @@ -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;
}
Expand Down

0 comments on commit a66c66e

Please sign in to comment.