The title says it all!! If you have been paying any attention at all to us here at wolfSSL, you will know that we are very proud of our wolfHSM product that already runs on the Aurix Tricore. What we have not been focusing on is the post-quantum algorithms that work with wolfHSM. Let’s use this blog post to fix that oversight.
In this post we will be focusing on ML-KEM, ML-DSA, and especially LMS and XMSS as they are all implemented in wolfCrypt and are therefore available in wolfHSM to protect you from the oncoming quantum threat.
First of all, ML-KEM is a Key Encapsulation Mechanism and generally used for key establishment. In most protocols this means it is used ephemerally, but because of the security properties inherent in the algorithm, it can also be used statically. That means it is fine for wolfHSM to generate an ML-KEM private key and use it multiple times under the protection of the HSM core.
Naturally, as MLDSA is a general purpose post-quantum signature scheme, wolfHSM has an opportunity to help just like in the case of ECDSA or RSA.
Now, where wolfHSM provides a unique offering is LMS and XMSS. These are stateful hash-based signature schemes which are great for firmware and software signing. That said, there is a state associated with the private key and that state MUST be properly managed. A consequence of improper management is that the key pair must be revoked and all signatures encountered after the point of revocation cannot be trusted.
Software libraries that implement signing by stateful hash-based signature schemes, such as wolfSSL, must trust the application developer to properly manage the state. In the case of wolfHSM, the wolfSSL team’s expertise can come into play to ensure proper management of the state. The application developer no longer needs to be an expert in post-quantum algorithms; simply a user of them.
If you’d like to learn how wolfHSM can support your post-quantum migration or have any questions, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now