Skip to content

Add support for LMS and XMSS#352

Draft
padelsbach wants to merge 4 commits intowolfSSL:mainfrom
padelsbach:lms-xmss
Draft

Add support for LMS and XMSS#352
padelsbach wants to merge 4 commits intowolfSSL:mainfrom
padelsbach:lms-xmss

Conversation

@padelsbach
Copy link
Copy Markdown
Contributor

Requires wolfSSL/wolfssl#10380 and #336 to be merged first.

Frauschi and others added 4 commits May 4, 2026 11:29
Implement full client-server ML-KEM (Module-Lattice-Based Key Encapsulation
Mechanism) support across all wolfHSM layers, enabling post-quantum key
exchange operations to be offloaded to the HSM.

Client API (wh_client_crypto):
- Key management: import, export, set/get key ID
- Key generation: MakeExportKey (ephemeral) and MakeCacheKey (server-cached)
- Encapsulation and decapsulation operations
- DMA variants for all operations

Server handling (wh_server_crypto):
- Request handlers for ML-KEM keygen, encapsulate, and decapsulate
- Auto-import with evict-after-use for uncached keys
- DMA request handlers

Crypto callback integration (wh_client_cryptocb):
- Register PQC KEM keygen/encaps/decaps handlers so wolfCrypt ML-KEM calls
  are transparently forwarded to the HSM via WH_DEV_ID

Message layer (wh_message_crypto):
- Define request/response structures for keygen, encapsulate, decapsulate
- Endian translation functions for cross-platform support

Shared utilities (wh_crypto):
- ML-KEM key serialization/deserialization with automatic level probing

Supports all three ML-KEM parameter sets (512, 768, 1024). Includes tests
for all operations and DMA paths, and benchmarks for keygen, encaps, and
decaps at each security level.

Also fixes key export response to use actual stored key length from NVM
metadata instead of the request size.
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