From 020d65be60c7a168937db085c7132a79b36f8968 Mon Sep 17 00:00:00 2001 From: kaleb-himes Date: Mon, 30 Mar 2026 16:19:10 -0600 Subject: [PATCH 1/5] Add DRBG_CONT_FIPS_E to FAQ + v6,v7 delta start --- wolfSSL-FIPS-FAQ/src/section01.md | 13 +++--- wolfSSL-FIPS-FAQ/src/section02.md | 72 +++++++++++++++++++++++++++++++ 2 files changed, 80 insertions(+), 5 deletions(-) diff --git a/wolfSSL-FIPS-FAQ/src/section01.md b/wolfSSL-FIPS-FAQ/src/section01.md index c1fa4c61..dd4864db 100644 --- a/wolfSSL-FIPS-FAQ/src/section01.md +++ b/wolfSSL-FIPS-FAQ/src/section01.md @@ -2,7 +2,7 @@ This page lists some of the most common issues and questions that are recieved by our wolfSSL security experts, along with their responses. This FAQ is useful for solving general questions that pertain to building/implementing wolfSSL FIPS. If this page does not provide an answer to your question, please feel free to check the wolfSSL Manual, or contact us at support@wolfssl.com. -Last Updated: 8 Dec 2025 +Last Updated: 30 Mar 2026 ## Questions @@ -18,10 +18,13 @@ Last Updated: 8 Dec 2025 1. [Will my applications that are linked agaist the 140-2 module still work with the 140-3 module?](./section02.md#will-my-app-for-1402-still-work-with-1403) 2. [The wc_SetSeed_Cb() callback and the TLS Layer:](./section02.md#wc-setseed-and-tls) 3. [The wc_SetSeed_Cb() callback and a custom seed generation function:](./section02.md#wc-setseed-and-custom-genseed) - 4. [Threading consideration for all CASTs():](./section02.md#threading-and-casts) - 5. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) - 6. [Key Access Management](./section02.md#key-access-management) - 7. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) + 4. [The POST](./section02.md#the-post) + 5. [Threading consideration for all CASTs():](./section02.md#threading-and-casts) + 6. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) + 7. [Key Access Management](./section02.md#key-access-management) + 8. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) 1. [API's that require UNLOCK before first use (should also be re-LOCKED after use):](./section02.md#apis-to-unlock) +6. [Moving from v5 to v6 or even v7, what's new?](./section02.md#moving-from-v5-to-v6-or-even-v7-whats-new) +7. [Long-running application(s) & DRBG_CONT_FIPS_E or RNG_FAILURE_E errors](./section02.md#long-running-applications-drbg_cont_fips_e-or-rng_failure_e-errors) diff --git a/wolfSSL-FIPS-FAQ/src/section02.md b/wolfSSL-FIPS-FAQ/src/section02.md index 3c036f98..a1d48a60 100644 --- a/wolfSSL-FIPS-FAQ/src/section02.md +++ b/wolfSSL-FIPS-FAQ/src/section02.md @@ -397,3 +397,75 @@ v7.0.0 (upcoming) * Will have some additional services listed here for Post Quantum key material ``` +## Moving from v5 to v6 or even v7, what's new? + +v6 offers new algorithms not available in v5: +``` +* SRTP-KDF +* AES-XTS (256, 512) +* AES-GCM Streaming mode of operation! +* AES-CFB (1, 8, 128) +* AES-KW +* PBKDF2 +* RSA, ECC, DH FIPS 186-5 upgrade from 186-4! +* ED25519 +* ED448 +* SHAKE128 +* SHAKE256 +* Optional ESV SP800-90B certifiable entropy source w/ SHA3 conditioning function +``` + +In addition to v5 and v6 algorithms, v7 offers new algorithms for PQ and NSA 2.0 suite considerations! +``` +* ML-KEM +* ML-DSA +* SLH-DSA +* LMS (verify only) +* XMSS (verify only) +* SHA512-DRBG (+ Option to run-time disable SHA256-DRBG for NSA 2.0 suite) +* SHA512-based integrity check (no SHA256 use by default for NSA 2.0 suite) +* SHA512/224 & SHA512/256 truncated variants +* RSA, ECC, DH getting additional hash modes for SHAKE and SHA512 variants +* Optional ESV SP800-90B certifiable entropy source w/ SHA3 conditioning function +``` + +## Long-running application(s) & DRBG_CONT_FIPS_E or RNG_FAILURE_E errors... +After millions of calls to wc_InitRng or wc_RNG_GenerateBlock I see these DRBG errors and then +all subsequent wolfCrypt API calls just return FIPS_NOT_ALLOWED_E. What is happening and how do I resolve this? + +A: This is expected behavior related to the DRBG continuous health test (CRNGT) used in the +FIPS module. The legacy CRNGT has a false-positive rate of roughly 1 in every 134 million +invocations. For long-running applications that never power cycle, a false positive will +eventually occur. When it does the DRBG enters an error state and the module will not allow +any further cryptographic operations that depend on a DRBG. This is required by SP800-90Ar1" + +So the module is behaving correctly. + +Best practices to mitigate this in long-running applications: + + 1) Initialize the WC_RNG instance once globally and protect it with a mutex rather than + creating and destroying a new WC_RNG for each operation in every thread. + Initializing and freeing the RNG on every call dramatically increases the + rate at which you will encounter a false positive (the CRNGT runs during + wc_InitRng, so fewer calls to wc_InitRng means fewer opportunities to hit + a false positive). + + 2) If a DRBG continuous test failure does occur, the application can recover by restarting + the executable (or the process using the wolfCrypt shared library). On a modern OS, + unloading and reloading the shared object is equivalent to a power cycle of the module + from the FIPS perspective. A full device power cycle is NOT required when using a shared object. + + 3) wolfSSL strongly recommends that persistent connections be shut down and a new + handshake performed at least once every 24 to 48 hours. Re-negotiating ephemeral keys + every 8 - 10 minutes (complete shutdown and fresh handshake) is ideal, do + not leave a DTLS session active for 24, 38, 72... hours or more, this will + increase your chances of hitting a false positive as well. + +NOTE: The upcoming v7.0.0 FIPS module will replace the legacy CRNGT with the newer +Repetition Count Test (RCT) and Adaptive Proportion Test (APT) as defined in SP800-90B. +These tests are more mathematically robust and will significantly reduce the false-positive +rate, alleviating this issue for long-lived applications. However, because any change inside +the FIPS boundary requires re-validation, as such these newer tests cannot be back-ported to older validated +modules (e.g. v5.x or v6.x). Customers running an older module version will need to use the +mitigation strategies above until they migrate to the v7.0.0 module once it is validated. + From 571d4f747bf3a40f0e8219ae774cde67e5d40678 Mon Sep 17 00:00:00 2001 From: kaleb-himes Date: Mon, 30 Mar 2026 16:22:50 -0600 Subject: [PATCH 2/5] Fix typo (38->48) and both protocols --- wolfSSL-FIPS-FAQ/src/section02.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wolfSSL-FIPS-FAQ/src/section02.md b/wolfSSL-FIPS-FAQ/src/section02.md index a1d48a60..d5b3bb8f 100644 --- a/wolfSSL-FIPS-FAQ/src/section02.md +++ b/wolfSSL-FIPS-FAQ/src/section02.md @@ -458,7 +458,7 @@ Best practices to mitigate this in long-running applications: 3) wolfSSL strongly recommends that persistent connections be shut down and a new handshake performed at least once every 24 to 48 hours. Re-negotiating ephemeral keys every 8 - 10 minutes (complete shutdown and fresh handshake) is ideal, do - not leave a DTLS session active for 24, 38, 72... hours or more, this will + not leave a TLS/DTLS session active for 24, 48, 72... hours or more, this will increase your chances of hitting a false positive as well. NOTE: The upcoming v7.0.0 FIPS module will replace the legacy CRNGT with the newer From b73ece42eaaefea2c667e0f599169b0de7d5cb88 Mon Sep 17 00:00:00 2001 From: kaleb-himes Date: Mon, 30 Mar 2026 17:17:30 -0600 Subject: [PATCH 3/5] Fix duplication in table of contents --- wolfSSL-FIPS-FAQ/src/section01.md | 1 - 1 file changed, 1 deletion(-) diff --git a/wolfSSL-FIPS-FAQ/src/section01.md b/wolfSSL-FIPS-FAQ/src/section01.md index dd4864db..d7bf4ba2 100644 --- a/wolfSSL-FIPS-FAQ/src/section01.md +++ b/wolfSSL-FIPS-FAQ/src/section01.md @@ -22,7 +22,6 @@ Last Updated: 30 Mar 2026 5. [Threading consideration for all CASTs():](./section02.md#threading-and-casts) 6. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) 7. [Key Access Management](./section02.md#key-access-management) - 8. [wc_SetSeedCb() a bit unique with relation to CAST's:](./section02.md#setseedcb-and-casts) 1. [API's that require UNLOCK before first use (should also be re-LOCKED after use):](./section02.md#apis-to-unlock) 6. [Moving from v5 to v6 or even v7, what's new?](./section02.md#moving-from-v5-to-v6-or-even-v7-whats-new) 7. [Long-running application(s) & DRBG_CONT_FIPS_E or RNG_FAILURE_E errors](./section02.md#long-running-applications-drbg_cont_fips_e-or-rng_failure_e-errors) From 1104cd9100bdfd8a17b86dfea287ee2bc53fa0bf Mon Sep 17 00:00:00 2001 From: Kaleb Himes Date: Tue, 31 Mar 2026 11:19:15 -0600 Subject: [PATCH 4/5] Update wolfSSL-FIPS-FAQ/src/section02.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- wolfSSL-FIPS-FAQ/src/section02.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wolfSSL-FIPS-FAQ/src/section02.md b/wolfSSL-FIPS-FAQ/src/section02.md index d5b3bb8f..5bca85f0 100644 --- a/wolfSSL-FIPS-FAQ/src/section02.md +++ b/wolfSSL-FIPS-FAQ/src/section02.md @@ -437,7 +437,7 @@ A: This is expected behavior related to the DRBG continuous health test (CRNGT) FIPS module. The legacy CRNGT has a false-positive rate of roughly 1 in every 134 million invocations. For long-running applications that never power cycle, a false positive will eventually occur. When it does the DRBG enters an error state and the module will not allow -any further cryptographic operations that depend on a DRBG. This is required by SP800-90Ar1" +any further cryptographic operations that depend on a DRBG. This is required by SP 800-90A Rev. 1. So the module is behaving correctly. From 431b5c31595ff01dd8c7e211bf232b03492e9be5 Mon Sep 17 00:00:00 2001 From: Kaleb Himes Date: Tue, 31 Mar 2026 11:20:04 -0600 Subject: [PATCH 5/5] Update wolfSSL-FIPS-FAQ/src/section02.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- wolfSSL-FIPS-FAQ/src/section02.md | 34 +++++++++++++++---------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/wolfSSL-FIPS-FAQ/src/section02.md b/wolfSSL-FIPS-FAQ/src/section02.md index 5bca85f0..75def2f3 100644 --- a/wolfSSL-FIPS-FAQ/src/section02.md +++ b/wolfSSL-FIPS-FAQ/src/section02.md @@ -443,23 +443,23 @@ So the module is behaving correctly. Best practices to mitigate this in long-running applications: - 1) Initialize the WC_RNG instance once globally and protect it with a mutex rather than - creating and destroying a new WC_RNG for each operation in every thread. - Initializing and freeing the RNG on every call dramatically increases the - rate at which you will encounter a false positive (the CRNGT runs during - wc_InitRng, so fewer calls to wc_InitRng means fewer opportunities to hit - a false positive). - - 2) If a DRBG continuous test failure does occur, the application can recover by restarting - the executable (or the process using the wolfCrypt shared library). On a modern OS, - unloading and reloading the shared object is equivalent to a power cycle of the module - from the FIPS perspective. A full device power cycle is NOT required when using a shared object. - - 3) wolfSSL strongly recommends that persistent connections be shut down and a new - handshake performed at least once every 24 to 48 hours. Re-negotiating ephemeral keys - every 8 - 10 minutes (complete shutdown and fresh handshake) is ideal, do - not leave a TLS/DTLS session active for 24, 48, 72... hours or more, this will - increase your chances of hitting a false positive as well. +1. Initialize the WC_RNG instance once globally and protect it with a mutex rather than + creating and destroying a new WC_RNG for each operation in every thread. + Initializing and freeing the RNG on every call dramatically increases the + rate at which you will encounter a false positive (the CRNGT runs during + wc_InitRng, so fewer calls to wc_InitRng means fewer opportunities to hit + a false positive). + +2. If a DRBG continuous test failure does occur, the application can recover by restarting + the executable (or the process using the wolfCrypt shared library). On a modern OS, + unloading and reloading the shared object is equivalent to a power cycle of the module + from the FIPS perspective. A full device power cycle is NOT required when using a shared object. + +3. wolfSSL strongly recommends that persistent connections be shut down and a new + handshake performed at least once every 24 to 48 hours. Re-negotiating ephemeral keys + every 8 - 10 minutes (complete shutdown and fresh handshake) is ideal, do + not leave a TLS/DTLS session active for 24, 48, 72... hours or more, this will + increase your chances of hitting a false positive as well. NOTE: The upcoming v7.0.0 FIPS module will replace the legacy CRNGT with the newer Repetition Count Test (RCT) and Adaptive Proportion Test (APT) as defined in SP800-90B.