Implement client api to generate and cache a random key#437
Implement client api to generate and cache a random key#437AlexLanzano wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds a new keystore operation and client API for server-side generation of random key material directly into the keystore cache, returning only the assigned keyId to the client. This fits into wolfHSM’s key-management workflow by enabling “generate-on-server then use-by-ID” flows without uploading key bytes from the client.
Changes:
- Introduces
wh_Client_KeyCacheRandom*request/response/blocking APIs and corresponding wire message + translation. - Adds server keystore handling for
WH_KEY_CACHE_RANDOM, generating random bytes into a cache slot via the server RNG. - Adds a crypto client test for key generation + basic validation, and documents the new API in the manual/API reference.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| wolfhsm/wh_message.h | Adds WH_KEY_CACHE_RANDOM action ID. |
| wolfhsm/wh_message_keystore.h | Defines CacheRandom request message + translator prototype. |
| wolfhsm/wh_client.h | Declares new wh_Client_KeyCacheRandom* public APIs with docstrings. |
| src/wh_client.c | Implements the new client request/response/blocking helpers. |
| src/wh_server_keystore.c | Adds _KeystoreCacheRandomKey() and server handler for the new action. |
| src/wh_message_keystore.c | Implements request translation for CacheRandom. |
| test/wh_test_crypto.c | Adds whTest_KeyCacheRandom and wires it into the crypto client test flow. |
| docs/src/chapter05.md | Adds a user-facing example and conceptual documentation for server RNG key caching. |
| docs/src/appendix01.md | Adds API reference documentation for the new functions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
AlexLanzano
force-pushed
the
gen-rng-key
branch
2 times, most recently
from
8c0dc0e to
8bb2ab6
Compare
bigbrett
left a comment
bigbrett
left a comment
There was a problem hiding this comment.
overall looks good, just a few tweaks
| } | ||
|
|
||
| memcpy((uint8_t*)slotMeta, (uint8_t*)meta, sizeof(whNvmMetadata)); | ||
| _MarkKeyCommitted(_GetCacheContext(server, meta->id), meta->id, 0); |
There was a problem hiding this comment.
@AlexLanzano Just noticed this. Why are we marking this as committed? Is it because we never want it to go to NVM and it is meant to be cache-only and auto-evictable? I'm wondering if we want to actually have this just be treated like any other key?
There was a problem hiding this comment.
Looks like Im setting it as uncommitted here, no? I used the same logic as the regular key cache handler
Add wh_Client_KeyCacheRandom client API to have the server generate a key from its RNG, cache it, and return only the keyId
Add the client request/response/blocking triplet: wh_Client_KeyCacheRandomRequest_ex, wh_Client_KeyCacheRandomRequest, wh_Client_KeyCacheRandomResponse, and the blocking wh_Client_KeyCacheRandom
Add WH_KEY_CACHE_RANDOM keystore action and whMessageKeystore_CacheRandomRequest message (reusing CacheResponse) with its wh_MessageKeystore_TranslateCacheRandomRequest translation function
Add server handler for WH_KEY_CACHE_RANDOM plus the _KeystoreCacheRandomKey helper, generating random bytes directly into a cache slot via wc_RNG_GenerateBlock
Add whTest_KeyCacheRandom test (generate → export-verify size/label/non-zero → uniqueness → evict) wired into the crypto client test suite
Document the new API in docs/