I am a cybersecurity researcher investigating post-quantum approaches to firmware authentication, including the use of LMS on resource-constrained embedded systems.
Would the wolfSSL developers consider adding an incremental LMS/HSS verification API, similar to an Init/Update/Final interface?
Currently, wc_LmsKey_Verify() requires the complete message to be supplied as a contiguous buffer. For embedded firmware verification, the authenticated image may be several megabytes in size and is typically processed incrementally from flash or another storage device. Requiring the complete image to be buffered can therefore be impractical on memory-constrained platforms.
Since LMS/LM-OTS verification hashes the message internally, it appears that verification could support an interface such as:
wc_LmsKey_VerifyInit(...)
wc_LmsKey_VerifyUpdate(..., data, dataSz)
wc_LmsKey_VerifyFinal(...)
This would allow RFC 8554-compatible signatures to be verified incrementally with bounded RAM usage, without requiring applications to introduce a separate pre-hashing convention.
I am a cybersecurity researcher investigating post-quantum approaches to firmware authentication, including the use of LMS on resource-constrained embedded systems.
Would the wolfSSL developers consider adding an incremental LMS/HSS verification API, similar to an Init/Update/Final interface?
Currently,
wc_LmsKey_Verify()requires the complete message to be supplied as a contiguous buffer. For embedded firmware verification, the authenticated image may be several megabytes in size and is typically processed incrementally from flash or another storage device. Requiring the complete image to be buffered can therefore be impractical on memory-constrained platforms.Since LMS/LM-OTS verification hashes the message internally, it appears that verification could support an interface such as:
This would allow RFC 8554-compatible signatures to be verified incrementally with bounded RAM usage, without requiring applications to introduce a separate pre-hashing convention.