benchmark: time ML-KEM encaps/decaps as one round trip

[Frauschi]

What

The ML-KEM benchmark rows created their key with wh_Client_MlKemMakeExportKey, which returns the key to the client without caching it server-side, leaving key->devCtx empty. Every wh_Client_MlKem{Encapsulate,Decapsulate} in the timed loop therefore took the implicit-import path: ship the whole private key to the server (1632 bytes for ML-KEM-512, up to 3168 for ML-KEM-1024), run the operation with the evict flag set, leave the cache empty for the next iteration.

That is two round trips per measurement instead of one, and the extra one carries a payload larger than anything the operation itself sends. ML-KEM was the only module doing this - AES, CMAC, ECC, RSA and ML-DSA all cache their key once before the loop and reference it by ID - so the ML-KEM rows were reported against a different amount of transport work than the rows they sit next to.

This generates the key straight into the server cache with wh_Client_MlKemMakeCacheKey, binds the ID to the client key struct, and evicts once after the loop. Key setup was already outside the timed section, so nothing moves in or out of the measurement.

The KEY-GEN rows keep wh_Client_MlKemMakeExportKey deliberately - those measure generating a key and getting it back, which is what the ECC and ML-DSA key generation rows measure too.

Second commit

Making the bench rows use a cached key exposed a sizing gap. wh_Server_MlKemKeyCacheImport always requests a WC_ML_KEM_MAX_PRIVATE_KEY_SIZE (3168) slot at every security level, but WOLFHSM_CFG_SERVER_KEYCACHE_BIG_BUFSIZE defaults to 8192 only when ML-DSA, XMSS or LMS is enabled, and to 1200 otherwise. An ML-KEM-only build got a buffer less than half the size every cache keygen and import needs, failing at run time with WH_ERROR_BUFFER_SIZE and nothing at build time to say why.

• Added WOLFSSL_HAVE_MLKEM to the big-buffer condition.
• Added the compile-time assert ML-DSA already carries next to its own cache import, so an undersized override fails to build with a message naming the setting.
• Added a positive cached-key-by-ID DMA encaps/decaps test. That combination had no coverage: the only place a cached-by-ID key met the DMA calls was the negative usage-policy case, and the positive DMA test used a key whose devCtx was still erased, so it exercised the implicit-import path instead.

Testing

Check	Result
wh_test full suite, DMA=1 and plain	pass
POSIX benchmark, DMA=1 and plain	pass, all 18 ML-KEM rows
Builds, both configs	clean at -std=c90 -Werror -Wall -Wextra
Undersized BIG_BUFSIZE	new assert fires, names the setting

Round trips were measured with a probe on client->comm->seq around the timed loop. The ten iterations of a default run (WOLFHSM_CFG_BENCH_PK_ITERS) advanced it by twenty before and by ten after, at all three security levels, on both the inline and the DMA path, encapsulation and decapsulation alike.

The new test was checked against a deliberate break: removing the wh_Client_MlKemSetKeyId call makes it fail rather than pass quietly.

Notes

The gain is invisible on a POSIX in-process transport, where a round trip is a memcpy, and is the whole story on a real IPC boundary. On a real target, where each round trip costs tens of microseconds, this improves ML-KEM benchmark results substantially.

The DMA rows share the non-DMA setup call deliberately. wh_Client_MlKemMakeCacheKeyDma is the DMA form of wh_Client_MlKemMakeCacheKeyAndExportPublic, not of wh_Client_MlKemMakeCacheKey: it requires a public key out, which the timed operations do not need.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #504

Scan targets checked: wolfhsm-core-bugs, wolfhsm-crypto-bugs, wolfhsm-src

No new issues found in the changed files. ✅