Fix fenrir findings across wolfProvider

[JeremiahM37]

Description

Fixes F-174, F-175, F-176, F-186, F-187, F-188, F-260, F-261, F-262, F-263, F-272, F-273, F-274, F-400, F-399, F-505, F-506, F-507, F-508, F-509, F-831, F-832, F-833, F-834, F-1626, F-1627, F-1628, F-1635, F-1639, F-1640, F-1641, F-1642, F-1643

• Chunk digest/HMAC/CMAC/AES/DES3 update calls to avoid size_t to word32 truncation on >4GB
  inputs
• Fix SINGLE_THREADED → WP_SINGLE_THREADED mutex guards across all kmgmt files
• Replace prefix-match XSTRNCMP with exact XSTRCMP in param/name lookups and fix sizeof
  copy-paste errors
• Secure-clear key material in CMAC/GMAC free, EPKI decrypt, ECX key compare, and X25519
  derive (constant-time)
• Guard tagLen/outLen assignment, KBKDF XMEMCPY NULL IV, GCM dinit NULL IV, and add RSA TLS
  implicit rejection
• Fix PEM footer length, base64 arithmetic, and hex dump off-by-one

New Tests

• test_digest_multi_update: SHA-256 single update vs. many 64-byte updates, verify match across OpenSSL and wolfProvider
• test_hmac_multi_update: HMAC single update vs. many 128-byte updates, cross-provider comparison
• test_cmac_multi_update: CMAC single update vs. many 16-byte updates, cross-provider comparison
• test_aes_cbc_large_update: AES-256-CBC encrypt/decrypt roundtrip with chunked 1024-byte updates, cross-provider comparison
• test_aes128_gcm_key_then_iv: GCM decrypt init with key only (NULL IV), then set IV via ctrl, encrypt/decrypt roundtrip
• test_rsa_param_prefix_match: Imports RSA key with prefix param "rsa-factor" —
  incorrectly matches "rsa-factor1" on master
• test_rsa_kem_prefix_match: Sets KEM operation to "RSASVE_extra" — incorrectly
  accepted on master

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #387

Scan targets checked: wolfprovider-bugs, wolfprovider-src

No new issues found in the changed files. ✅

[aidangarske]

Please don't just fix without adding test suites and verifying the actual failures here. We should write unit tests, validate these fail correctly, then fix so we know these are fixed and now tested.

[JeremiahM37]

Please don't just fix without adding test suites and verifying the actual failures here. We should write unit tests, validate these fail correctly, then fix so we know these are fixed and now tested.

The fixes in this PR are primarily defensive hardening, so direct testing is limited. Added tests that validate the fixed code paths.

[dgarske]

🐺 Skoll Code Review

Overall recommendation: APPROVE
Findings: 4 total — 3 posted, 1 skipped

Posted findings

• [Medium] test_digest_multi_update declared/registered outside WP_HAVE_DIGEST guard — test/unit.h:120, test/unit.c:205
• [Medium] RSA TLS implicit rejection writes 48 bytes without defensive outSize check — src/wp_rsa_asym.c:501
• [Medium] CMAC free does not call wc_CmacFree unlike GMAC's wc_AesFree addition — src/wp_cmac.c:90-95

Skipped findings

• [Low] Inconsistent chunk max values could benefit from named constants

Review generated by Skoll via openclaw

[dgarske]

🟡 [Medium] RSA TLS implicit rejection writes 48 bytes without defensive outSize check
💡 SUGGEST question

The implicit rejection code always writes WOLFSSL_MAX_MASTER_KEY_LENGTH (48) bytes to out in the constant-time select loop (line 501), regardless of outSize. While the size query path (line 414) returns 48, ensuring callers allocate enough, there is no defensive check that outSize >= WOLFSSL_MAX_MASTER_KEY_LENGTH before the loop. A misuse (e.g., caller passes a smaller buffer) would cause an out-of-bounds write. The old code had similar assumptions but the new 48-byte unconditional write makes it more explicit. This is the TLS pre-master secret path where 48 bytes is always expected, so it's low practical risk.

Suggestion:

Suggested change

	for (i = 0; i < WOLFSSL_MAX_MASTER_KEY_LENGTH; i++) {
	Add a defensive check before the implicit rejection block:
	if (ok && outSize < WOLFSSL_MAX_MASTER_KEY_LENGTH) {
	ok = 0;
	}

[dgarske]

🟡 [Medium] CMAC free does not call wc_CmacFree unlike GMAC's wc_AesFree addition
💡 SUGGEST convention

The PR correctly added wc_AesFree(&macCtx->gmac.aes) in wp_gmac_free to properly release wolfSSL AES resources. However, the analogous wp_cmac_free (also modified in this PR to use OPENSSL_clear_free) does not call wc_CmacFree on the Cmac struct. wolfSSL's wc_CmacFree exists and is used in the codebase (e.g., wp_kbkdf.c:521). While the OPENSSL_clear_free zeroes memory, it doesn't run wolfSSL's cleanup for the internal AES state (which may hold hardware crypto handles on some platforms). Since this PR already touches wp_cmac_free, it would be consistent to add the wolfSSL cleanup call here too.

Suggestion:

Suggested change

	{
	static void wp_cmac_free(wp_CmacCtx* macCtx)
	{
	if (macCtx != NULL) {
	#ifndef HAVE_FIPS
	wc_CmacFree(&macCtx->cmac);
	#endif
	OPENSSL_cleanse(macCtx->key, macCtx->keyLen);
	OPENSSL_clear_free(macCtx, sizeof(*macCtx));
	}
	}