Juliusz Sosinowicz
38b52d8079
### `wolfssl/internal.h`
- **`InternalTicket` struct gains a flexible array member**: A new `peerCert[]` field (with a preceding `peerCertLen[2]`) is added to `InternalTicket`. This allows the peer's DER-encoded certificate to be stored directly inside the session ticket.
- **`ExternalTicket` struct becomes variable-length**: The `enc_ticket` field is changed from a fixed-size array to a flexible array member (`byte enc_ticket[]`). The `mac` field is removed from the struct — the MAC is now placed dynamically after the encrypted data in `enc_ticket`.
### `src/internal.c`
- The `GetRecordHeader` function now only adds `MAX_COMP_EXTRA` to the maximum allowed record size when `ssl->options.usingCompression` is true, tightening the length validation. The max fragment length extension check is now much stricter.
- **Peer certificate is serialized into the ticket**: During ticket creation, the code attempts to find the peer certificate from `ssl->peerCert` or from `ssl->session->chain` (fallback). If found and within `MAX_TICKET_PEER_CERT_SZ`, it's copied into `it->peerCert`. DTLS is explicitly excluded (peer cert length set to 0) to keep ticket size small for MTU constraints. If `HAVE_MAX_FRAGMENT` is defined and max fragment is not `MAX_RECORD_SIZE` for TLS 1.3, the cert is also skipped since `SendTls13NewSessionTicket` doesn't support fragmentation yet.
- **Peer certificate restoration from ticket**: On successful ticket decryption, if the ticket contains a peer certificate (`peerCertLen > 0`), it is decoded back into `ssl->peerCert` via `ParseCertRelative`/`CopyDecodedToX509`, and also added to `ssl->session->chain` via `AddSessionCertToChain`.
- The `CLEAR_ASN_NO_PEM_HEADER_ERROR` macro was rewritten to loop and remove all consecutive PEM no-start-line errors (not just the last one), wrapped in a `do { ... } while(0)` for safety.
- The `SendTicket` function is simplified to use `SendHandshakeMsg` to support fragmenting the larger ticket.
---
### `src/x509.c`
- `loadX509orX509REQFromPemBio` now accepts `TRUSTED_CERT_TYPE` in addition to `CERT_TYPE` and `CERTREQ_TYPE`.
- **Streaming BIO support**: When `wolfSSL_BIO_get_len()` returns ≤ 0 (e.g., pipes/FIFOs), the function no longer returns an error. Instead, it sets an initial buffer of `MAX_X509_SIZE` and dynamically grows (doubling) up to `MAX_BIO_READ_BUFFER` (`MAX_X509_SIZE * 16`) as data is read byte-by-byte.
- **Alternate footer detection**: For `TRUSTED_CERT_TYPE`, the PEM reader also checks for the regular `CERT_TYPE` footer (`-----END CERTIFICATE-----`) in addition to the trusted cert footer (`-----END TRUSTED CERTIFICATE-----`), so it can parse either format.
- Removed two lines that set `cert->srcIdx` to `SIGALGO_SEQ` offset. This makes `cert->srcIdx` reflect the end of parsed certificate data. This is used by `loadX509orX509REQFromBuffer` to detect where auxiliary trust data begins in trusted certificates.
---
### `src/ssl_sk.c`
- Added a `STACK_TYPE_X509_CRL` case to `wolfssl_sk_dup_data` that calls `wolfSSL_X509_CRL_dup` for deep-copying CRL stack elements. Previously, `STACK_TYPE_X509_CRL` fell through to the unsupported default case.
---
### `wolfssl/openssl/ssl.h`
- `sk_X509_dup` now maps to `wolfSSL_shallow_sk_dup` (was `wolfSSL_sk_dup`/deep copy). This matches OpenSSL's behavior where `sk_X509_dup` does a shallow copy.
- `sk_SSL_CIPHER_dup` similarly changed to `wolfSSL_shallow_sk_dup`.
---
### `src/ssl_api_cert.c`
- When `ssl->ourCert` is `NULL` and the SSL owns its cert, the function now checks if `ssl->ctx->ourCert` points to the same certificate (by comparing DER buffers). If so, it returns the ctx's `X509` pointer directly. This maintains pointer compatibility for applications (like nginx OCSP stapling) that use the `X509*` from `SSL_CTX_use_certificate` as a lookup key.
### `src/bio.c`
- When `wolfssl_file_len` returns `WOLFSSL_BAD_FILETYPE` (now returned for pipes/FIFOs), `wolfSSL_BIO_get_len` treats it as length 0 instead of propagating the error.
---
### `tests/test-maxfrag.conf` and `tests/test-maxfrag-dtls.conf`
- Removed `DHE-RSA-AES256-GCM-SHA384` test entries because the ClientKeyExchange doesn't fit in the selected max fragment length.
wolfCrypt Test
Tool for performing cryptographic algorithm testing.
Example Output
Run on Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz.
./configure --enable-intelasm --enable-aesni --enable-sp --enable-sp-asm && make
./wolfcrypt/test/testwolfcrypt
------------------------------------------------------------------------------
wolfSSL version 4.0.0
------------------------------------------------------------------------------
error test passed!
MEMORY test passed!
base64 test passed!
asn test passed!
MD5 test passed!
SHA test passed!
SHA-224 test passed!
SHA-256 test passed!
SHA-384 test passed!
SHA-512 test passed!
SHA-3 test passed!
Hash test passed!
HMAC-MD5 test passed!
HMAC-SHA test passed!
HMAC-SHA224 test passed!
HMAC-SHA256 test passed!
HMAC-SHA384 test passed!
HMAC-SHA512 test passed!
HMAC-SHA3 test passed!
GMAC test passed!
Chacha test passed!
POLY1305 test passed!
ChaCha20-Poly1305 AEAD test passed!
AES test passed!
AES192 test passed!
AES256 test passed!
AES-GCM test passed!
RANDOM test passed!
RSA test passed!
DH test passed!
ECC test passed!
logging test passed!
mutex test passed!
memcb test passed!
Test complete
Windows Visual Studio
For building wolfCrypt test project in Visual Studio open the test.sln. For newer Visual Studio version it may prompt for a one-way upgrade. Then you may have to right-click on the solution and choose Retarget solution to update the project files for your Visual Studio version.
If you see an error about rc.exe then you'll need to update the "Target Platform Version". You can do this by right-clicking on the test project -> General -> "Target Platform Version" and changing to 8.1 (needs to match the wolfssl library project).
This solution includes the wolfSSL library project at <wolfssl-root>wolfssl.vcxproj and will compile the library, then the test project.
Jan 2026 - Reviewing the older FIPS compliant CRNGT test specified in FIPS 140-2 ss 4.9.2 vs the newer replacement tests RCT/ADP that are allowed to replace the CRNGT under the new FIPS 140-3 / ISO 19790 standard.
================================================================================ DRBG Continuous Health Test Statistical Analysis & Diagnostic Report
OVERVIEW
This document describes the statistical false positive behavior of the DRBG continuous health test in wc_RNG_TestSeed() and provides diagnostic tools to distinguish between:
- Statistical false positives (expected behavior)
- Entropy source depletion (under heavy concurrent load)
- Actual stuck entropy source (hardware failure)
BACKGROUND: THE ISSUE
The DRBG was experiencing high volumes of (DRBG_CONT_FIPS_E) on wc_InitRng() calls.
Example error: ERROR: wc_InitRng failed at iteration 330788 with code -209
This raises the question: Is this a bug in wc_RNG_TestSeed() or expected statistical behavior?
STATISTICAL ANALYSIS
The wc_RNG_TestSeed() Function Behavior:
- Compares ALL consecutive SEED_BLOCK_SZ chunks in the seed buffer
- With FIPS mode (typical configuration): SEED_SZ = 256 * 4 / 8 = 128 bytes (1024-bits) SEED_BLOCK_SZ = 4 bytes (default) (32-bits) seedSz passed to test = 132 bytes (SEED_SZ + SEED_BLOCK_SZ) Number of comparisons = ~32 consecutive block pairs
False Positive Probability Calculation:
- Probability one 4-byte block equals another random 4-byte block: 1/2^32
- With 32 comparisons per seed: 32/2^32 ≈ 1 in 134 million per wc_InitRng()
Test Configuration (Default):
- 40 threads × 100M iterations = 4 BILLION total wc_InitRng() calls
- Expected false positives: 4,000,000,000 × (32/2^32) ≈ 30 failures
Conclusion: Seeing failures around 1 in 30-140 million is EXPECTED STATISTICAL BEHAVIOR. Under heavy concurrent load (40 threads), entropy source depletion can also cause legitimate failures.
TESTING IT
Non-FIPS:
./configure CFLAGS="-DWC_RNG_SEED_DEBUG -DREALLY_LONG_DRBG_CONTINUOUS_TEST"
make
./wolfcrypt/test/testwolfcrypt
FIPS:
./configure --enable-fips=<flavor> CFLAGS="-DWC_RNG_SEED_DEBUG -DREALLY_LONG_DRBG_CONTINUOUS_TEST"
make
./fips-hash.sh
make
./wolfcrypt/test/testwolfcrypt
OUTPUTS EXPECTED
Non-FIPS:
Math: Multi-Precision: Wolf(SP) word-size=64 bits=4096 sp_int.c
------------------------------------------------------------------------------
wolfSSL version 5.8.4
------------------------------------------------------------------------------
macro test passed!
error test passed!
MEMORY test passed!
base64 test passed!
asn test passed!
MD5 test passed!
SHA test passed!
SHA-224 test passed!
SHA-256 test passed!
SHA-384 test passed!
SHA-512 test passed!
SHA-512/224 test passed!
SHA-512/256 test passed!
SHA-3 test passed!
RNG Entropy Source: getrandom() syscall
===============================================
DRBG Continuous Test Validation Suite
===============================================
FIPS Build: NO
--- Test 1: Basic RNG Functionality ---
Generated 32 random bytes successfully
[PASS] Basic RNG Functionality
--- Test 2: Multiple RNG Instances ---
Successfully operated 100 RNG instances concurrently
[PASS] Multiple RNG Instances
--- Test 3: FIPS Status Check ---
SKIPPED: FIPS not enabled
[PASS] FIPS Status Check
--- Test 4: RNG ReInit Test (multi-threaded) ---
Configuration: 40 threads × 100000000 iterations = 4000000000 total
Test Profile: Default (Aggressive multi-threaded)
Expected statistical false positive rate: ~29.80 failures
Duplicate block at offset 4:
Block 1: E6 E9 D1 7B
Block 2: E6 E9 D1 7B
Full seed buffer (52 bytes):
DA 93 B7 88 E6 E9 D1 7B E6 E9 D1 7B A5 4C C9 E9
13 EE D8 4C B3 C1 71 DE 32 37 17 F2 E7 A4 29 7D
9B 02 B0 0C EC 8D AC F5 DA B1 71 05 84 C0 61 75
59 6D 87 B5
ERROR: wc_InitRng failed at iteration 778551 with code -209
ERROR: wc_RNG_GenerateBlock failed at iteration 778551 with code -199
... (18 other failures truncated here for brevity) ... Duplicate block at offset 16: Block 1: C1 19 37 B1 Block 2: C1 19 37 B1 Full seed buffer (52 bytes): 62 66 5B D2 F5 54 47 9B 59 DD 0A 55 4B 52 8C 39 C1 19 37 B1 C1 19 37 B1 3F 62 CB 2E FE 56 65 4D 4F 0C A7 7D 1C 09 48 51 30 1B CA 00 56 9F 29 A7 E3 93 EF 8E ERROR: wc_InitRng failed at iteration 90467867 with code -209 ERROR: wc_RNG_GenerateBlock failed at iteration 90467867 with code -199 Thread 0 Succeeded ... 38 other thread results truncated here for brevity (all threads succeeded even though they experienced 1 or 2 failures in several of the threads) ... Thread 39 Succeeded Reinitialized RNG 4000000000 times across 40 threads Experienced 0 thread failures and 40 thread successes 20/4000000000 API calls failed <--- This is the bread and the butter of the test, we unfortunately expect to see ~29.80 failures, prior to the newer FIPS 140-3 RCT and ADP tests the CRNGT was required. Now the CRNGT is replaceable by the more mathematically robust RCT/ADP. [PASS] RNG Reinitialization
TESTING RESULTS with the CRNGT test:
Old implementation non-FIPS: Run 1 - 6 failures in 4 billion runs (100M per thread, 40 threads) Run 2 - 11 failures in 4 billion (100M per thread, 40 threads) Run 3 - 13 failures in 4 billion (100M per thread, 40 threads)
Old implementation with FIPS: (keeping in mind just a single failure means catastrophic failure for the entire module until power cycled): Run 1 - 3990118689 failures in 4 billion API calls (yikes)
TESTING RESULTS with the RCT/ADP tests in place of the CRNGT test:
New implementation non-FIPS: 4 billion successes New implementation FIPS: 4 billion successes