Skip to content

Fix ML-DSA cache import buffer sizing and test all security levels#6

Open
Frauschi wants to merge 1 commit into
mainfrom
claude/wolfhsm-ml-dsa-buffer-size-g3ZKt
Open

Fix ML-DSA cache import buffer sizing and test all security levels#6
Frauschi wants to merge 1 commit into
mainfrom
claude/wolfhsm-ml-dsa-buffer-size-g3ZKt

Conversation

@Frauschi
Copy link
Copy Markdown
Owner

@Frauschi Frauschi commented Jun 1, 2026

Summary

wh_Server_MlDsaKeyCacheImport() sized its cache-import buffer with the private-key DER macro (WC_MLDSA_*_PRV_KEY_DER_SIZE) instead of the full-keypair macro (MLDSA_MAX_BOTH_KEY_DER_SIZE). Since a freshly generated key holds both public and private parts, wh_Crypto_MlDsaSerializeKeyDer() encodes the full keypair via wc_MlDsaKey_KeyToDer(), which is larger than the private key alone. As a result, caching a generated keypair fails at ML-DSA-65/87 (BUFFER_E).

The value was used both to select/size the keystore cache slot and to bound the serialization. This now uses MLDSA_MAX_BOTH_KEY_DER_SIZE, matching the client-side serialization buffers.

Why CI missed it

The ML-DSA tests only exercised ML-DSA-44, whose keypair DER happens to fit within the (larger) private-key DER size of the highest enabled level. This PR parameterizes the existing ML-DSA test functions with a security level and loops the dispatcher over every enabled level (44/65/87), mirroring the ML-KEM test structure.

Verification

Built and run against wolfSSL master (5.9.1):

  • With the fix reverted: the suite aborts at ML-DSA-65 (MakeCacheKey returns BUFFER_E -173).
  • With the fix in place: all levels pass for both DMA and non-DMA builds, clean under -std=c90 -Werror -Wall -Wextra.

Generated by Claude Code

@Frauschi Frauschi force-pushed the claude/wolfhsm-ml-dsa-buffer-size-g3ZKt branch from b00c0c4 to 75eb07e Compare June 1, 2026 11:25
Copy link
Copy Markdown
Owner Author

Frauschi commented Jun 1, 2026

Pushed 75eb07e to fix the build (tcp) / build (tls) failures.

Root cause: the client-only example flow runs against the POSIX example server, whose key-cache BIG_BUFSIZE was hardcoded to 5120. The fix sizes the ML-DSA cache slot with MLDSA_MAX_BOTH_KEY_DER_SIZE (= WC_MLDSA_87_BOTH_KEY_DER_SIZE = 7520), which exceeds 5120, so wh_Server_KeystoreGetCacheSlot rejected it with WH_ERROR_BADARGS (-2000) — even at ML-DSA-44. The in-tree test/benchmark configs already use COMM_DATA_LEN (8192), so they passed.

Fix: set the example server's WOLFHSM_CFG_SERVER_KEYCACHE_BIG_BUFSIZE to WOLFHSM_CFG_COMM_DATA_LEN, matching the other server configs.

Verified locally by reproducing the exact client-only CI flow (build server → run → build+run client-only test with ASAN) for both TCP and TLS — both now pass with ML-DSA exercised across all three levels. Watching the new CI run.


Generated by Claude Code

Comment thread examples/posix/wh_posix_server/wolfhsm_cfg.h Outdated
Comment thread src/wh_server_crypto.c Outdated
Comment thread test/wh_test_crypto.c Outdated
The server ML-DSA cache-import buffer was sized with the private-key DER
macro instead of the full-keypair macro (MLDSA_MAX_BOTH_KEY_DER_SIZE),
so caching a generated keypair failed at ML-DSA-65/87. CI missed it
because the ML-DSA tests only ran ML-DSA-44; the existing tests are now
parameterized to run across all enabled levels (44/65/87).

Also bump the POSIX example server's big key-cache buffer to hold the
largest ML-DSA-87 keypair DER (7520 bytes), matching the other server
configs, so the client-only example flow can cache keys at every level.
@Frauschi Frauschi force-pushed the claude/wolfhsm-ml-dsa-buffer-size-g3ZKt branch from 75eb07e to 764a627 Compare June 1, 2026 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants