Category: Post-Quantum

As artificial intelligence continues to evolve and transform industries, here at wolfSSL we are closely monitoring developments in Agent to Agent communication protocols such as A2A and SLIM. We recently wrote our blog post “A2A and wolfSSL” talking about how it is secured via TLS.

One particularly interesting development in this space is SLIM (Secure Low-Latency Interactive Messaging), a communication framework designed specifically for AI agents. What makes SLIM especially noteworthy from a security perspective is its choice of security protocol: Message Layer Security (MLS).

SLIM represents a new approach to AI agent communication, built on the gRPC framework and designed to provide secure, scalable messaging between multiple AI agents. SLIM addresses the unique challenges of group-based AI interactions where multiple agents need to communicate securely and efficiently.

MLS (Message Layer Security) is a relatively new cryptographic protocol standardized in RFC 9420 (https://datatracker.ietf.org/doc/rfc9420/). MLS is specifically designed for secure group messaging scenarios, making it an ideal choice for AI agent communication where multiple participants need to exchange information securely.

MLS provides several key security features that make it well-suited for AI agent communication:

• Quantum-safe end-to-end encryption ensures that communications between AI agents remain secure even against future quantum computing threats. MLS already incorporates ML-KEM and ML-DSA; NIST standardized post-quantum algorithms for key establishment and authentication.
• Dynamic group membership management allows AI agents to join and leave communication groups seamlessly. This is particularly important in distributed AI systems where agents may come online and offline dynamically based on computational needs or system requirements.
• The scalable key management system in MLS uses a tree-based structure that efficiently handles groups ranging from just a few agents to thousands of participants. This scalability is essential for large-scale AI deployments where numerous agents need to coordinate their activities.
• Allows the use of FIPS 140-3 approved algorithms such as AES-GCM, ECDSA and ECDHE; well-established, modern cryptographic primitives.

At wolfSSL, we recognize the importance of MLS in the evolving landscape of secure communications. We are actively working on an MLS implementation and have detailed our progress in our recent blog post about how MLS is on track for broader adoption (https://www.wolfssl.com/mls-messaging-layer-security-is-on-track/). Notably, wolfSSL will be the first to bring post-quantum algorithm implementations to MLS and therefore to SLIM, ensuring that AI agent communication remains secure even in the face of future quantum computing threats. Our commitment to supporting emerging security protocols ensures that developers building the next generation of secure applications, including AI agent communication systems like SLIM, have access to robust, well-tested cryptographic implementations. Moreover, with our multiple FIPS 140-3 certificates, we can provide cryptographic implementations that are tested and trusted within the federal government.

While wolfSSL does not currently implement MLS itself, our ongoing work continues to move forward. Want to see this effort accelerated? The best way to raise the priority is to let us know you’re interested. Send a message to facts@wolfssl.com to register your interest in SLIM and MLS.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Here at wolfSSL, we don’t just love coding! We love telling the world about what we code. To that end, we want you to understand the differences between LMS, XMSS, and SLH-DSA. Here are their official standard specifications:

• LMS (Leighton-Micali Hash-Based Signatures)
• XMSS (eXtended Merkle Signature Scheme)
• SLH-DSA (Stateless Hash-Based Digital Signature Standard)

The most important similarity of these three algorithms is that they are all hash-based signature schemes. Being hash-based, they are all quantum-safe signature schemes that rely on the tried and true security properties of proven battle-hardened hashing algorithms. They all use Merkle Trees to combine many data structure instances into a single public key.

These instances form the leaf nodes of the Merkle tree and are called WOTS (Winternitz One-Time Signature) in LMS and WOTS+ in XMSS. WOTS uses a “prefix construction” while WOTS+ uses a “prefix and bitmask construction” with random bitmasks to give it stronger security assumptions.

XMSS uses “L-trees” for compression, requiring more hashing operations. LMS does not have a corresponding compression scheme.

From the perspective of performance, LMS is consistently better (fewer clock cycles) for key generation, signing, and verification.

Generally speaking, XMSS has higher memory consumption, mostly during signing and verification.

While XMSS has various theoretical optimizations that would hamper interoperability, LMS remains more efficient in practice, but the difference is quite negligible. If security assurance via the bitmask constructions are important to you, then you should go with XMSS, but LMS is a better default.

The thing that LMS and XMSS both have in common is that they have a state and a limited number of available signatures; once that limit is hit, the private key must be discarded. The state is very important because if it is mismanaged, the signer might reuse a WOTS or WOTS+ which would then allow an attacker to forge signatures. With this formidable problem in mind, SLH-DSA was designed to eliminate this pitfall by not requiring state. SLH-DSA takes a randomized approach and makes conjectures on the probability of collisions. Note that the SLH-DSA equivalent of WOTS is a “few time signature”.

With the elimination of state, SLH-DSA opens the door to parallelization and distributed usage while LMS and XMSS would have signing operations tightly coupled to a single instance of the private key limiting it to serial signing operations.

Finally, one of the most important distinctions is that all three algorithms are standardized and recognized by NIST while only LMS and XMSS are approved for use under CNSA 2.0.

This concludes our comparison of LMS, XMSS and SLH-DSA. That said, this has only touched on the surface of these algorithms. Want deeper technical details? Looking to know which is most appropriate for your use-case? Have some more questions? Let us know by sending a message to facts@wolfSSL.com; we are always happy to continue the conversation!

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

A long, long time ago, we took some benchmarks for Kyber on STM32 NUCLEO-F446ZE. Back then, it was the NIST Submission of Kyber, and we were using the implementation from PQM4 as integration in wolfCrypt. Now, Kyber has evolved into ML-KEM, and we have our implementation! We decided to take some benchmarks on a newer STM32 hardware platform as well. Note that we now also have our implementation of ML-DSA which evolved from Dilithium so we also took benchmarking numbers for it as well.

Here are the numbers (some formatting changes have been made for readability):

RSA    2048  public        112 ops took 1.012 sec, avg   9.036 ms, 110.672 ops/sec
RSA    2048  private         4 ops took 1.298 sec, avg 324.500 ms,   3.082 ops/sec
DH     2048  key gen         7 ops took 1.150 sec, avg 164.286 ms,   6.087 ops/sec
DH     2048  agree           8 ops took 1.310 sec, avg 163.750 ms,   6.107 ops/sec
ML-KEM 512   key gen       248 ops took 1.000 sec, avg   4.032 ms, 248.000 ops/sec
ML-KEM 512   encap         262 ops took 1.000 sec, avg   3.817 ms, 262.000 ops/sec
ML-KEM 512   decap         198 ops took 1.000 sec, avg   5.051 ms, 198.000 ops/sec
ML-KEM 768   key gen       154 ops took 1.004 sec, avg   6.519 ms, 153.386 ops/sec
ML-KEM 768   encap         154 ops took 1.012 sec, avg   6.571 ms, 152.174 ops/sec
ML-KEM 768   decap         120 ops took 1.000 sec, avg   8.333 ms, 120.000 ops/sec
ML-KEM 1024  key gen        94 ops took 1.008 sec, avg  10.723 ms,  93.254 ops/sec
ML-KEM 1024  encap          94 ops took 1.016 sec, avg  10.809 ms,  92.520 ops/sec
ML-KEM 1024  decap          78 ops took 1.024 sec, avg  13.128 ms,  76.172 ops/sec
ECC   [SECP256R1] key gen  180 ops took 1.007 sec, avg   5.594 ms, 178.749 ops/sec
ECDH  [SECP256R1] agree     86 ops took 1.016 sec, avg  11.814 ms,  84.646 ops/sec
ECDSA [SECP256R1] sign     106 ops took 1.000 sec, avg   9.434 ms, 106.000 ops/sec
ECDSA [SECP256R1] verify    60 ops took 1.012 sec, avg  16.867 ms,  59.289 ops/sec
ML-DSA    44  key gen       52 ops took 1.011 sec, avg  19.442 ms,  51.434 ops/sec
ML-DSA    44  sign          18 ops took 1.086 sec, avg  60.333 ms,  16.575 ops/sec
ML-DSA    44  verify        46 ops took 1.008 sec, avg  21.913 ms,  45.635 ops/sec
ML-DSA    65  key gen       30 ops took 1.035 sec, avg  34.500 ms,  28.986 ops/sec
ML-DSA    65  sign          12 ops took 1.008 sec, avg  84.000 ms,  11.905 ops/sec
ML-DSA    65  verify        28 ops took 1.027 sec, avg  36.679 ms,  27.264 ops/sec
ML-DSA    87  key gen       18 ops took 1.047 sec, avg  58.167 ms,  17.192 ops/sec
ML-DSA    87  sign          10 ops took 1.255 sec, avg 125.500 ms,   7.968 ops/sec
ML-DSA    87  verify        16 ops took 1.003 sec, avg  62.687 ms,  15.952 ops/sec

This was done on an STM32 NUCLEO-F439ZI ARM Cortex M4 running at 168 MHz. The wolfSSL library was built with assembly optimizations, but does not use any hardware accelerated cryptography. Note: At the time of this writing the ML-DSA (Dilithium) is not using assembly optimizations, just well constructed C code.

• ML-DSA beats RSA quite nicely and is within an order of magnitude against ECDSA.
• ML-KEM beats DH and ECDH by a wide margin (thanks to assembly code for Thumb2).

Here are some special macro flags that were defined:

#define WOLFSSL_SP_ARM_CORTEX_M_ASM
#define WOLFSSL_HAVE_SP_RSA
#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_SMALL
#define SP_WORD_SIZE 32
#define GCM_TABLE_4BIT

#define HAVE_DILITHIUM
#define WOLFSSL_WC_DILITHIUM
#define WOLFSSL_DILITHIUM_SMALL

#define WOLFSSL_ARMASM
#define WOLFSSL_ARMASM_INLINE
#define WOLFSSL_ARMASM_NO_HW_CRYPTO
#define WOLFSSL_ARMASM_NO_NEON
#define WOLFSSL_ARMASM_THUMB2
#define WOLFSSL_ARM_ARCH 7

We support assembly optimizations on most algorithms and key sizes with Intel x86/x64, ARM Cortex-A/M/R, RISC-V and PowerPC.

If you are interested in seeing other algorithms benchmarked, or have questions about any of the above, please reach out to us at facts@wolfssl.com or call us at +1 425 245 8247 to let us know which ones!

Download wolfSSL Now

Here at wolfSSL, we are intimately aware of the needs of our embedded customers. It is always about the tradeoffs and optimizations that fit their unique use cases and needs. The tradeoffs are typically between speed, footprint size, and memory usage. In many of our blog posts, we like to focus on our speed performance, but in this post, we look at options around memory usage. This is especially important for our post-quantum algorithms, ML-KEM and ML-DSA, as they are generally faster or on par with their conventional counterparts, such as ECDSA and ECDH, but do use more memory.

We are going to focus on some experiments we did on a Raspberry Pi5. We built and ran wolfSSL’s testwolfcrypt and got some statistics. Here are the results:

Here are some interesting points we noticed in the data:

• Stack vs Heap Trade-off: WOLFSSL_SMALL_STACK configuration dramatically reduces stack usage (from ~23K-42K to 2,112 bytes)
• ML-KEM Memory Scaling: Memory usage scales predictably with security levels – ML-KEM-512 uses ~31K total, ML-KEM-768 uses ~44K, and ML-KEM-1024 uses ~59K in default configuration
• ML-DSA Higher Heap Usage: ML-DSA algorithms use significantly more heap memory (50K-120K) compared to MLKEM (7K-17K) in small code configuration
• Small Memory Optimization: Adding the small mem configuration flags reduces memory usage by 10 to 15 percent for ML-KEM and 50 to 65 percent for ML-DSA. Quite impressive!

If you’re wondering whether you will be able to use post-quantum algorithms on your system then these numbers should help you get an idea of the resource you will need to allocate.

Here are the configurations and commands used:

Let us know if you need us to get even tighter in terms of memory usage. Our cryptographers are wizards when it comes to exploiting tradeoffs!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

ML-KEM (Module-Lattice Key Encapsulation Mechanism) and HQC (Hamming Quasi-Cyclic) are both post-quantum cryptographic key encapsulation mechanisms (KEMs) designed to provide secure key exchange in the presence of CRQCs (Cryptographically Relevant Quantum Computers).

ML-KEM is based on the (M-LWE) Module Learning With Errors problem, which involves finding a short vector between two points in a high dimensional vector-space with special points called a lattice. HQC is based on the hardness of decoding random quasi-cyclic codes. This means matrices with columns that are shifts of the first column with some modifications. These domains of mathematics are both considered to be well studied in our modern times.

In terms of numbers, ML-KEM has smaller key sizes and ciphertext sizes when compared to HQC at the same security levels. ML-KEM is generally faster than HQC for all the KEM operations (key generation, encapsulation, decapsulation).

In terms of the status of the algorithms, ML-KEM has already been standardized by NIST, and code points for TLS 1.3 are already in draft standards at the IETF. HQC was recently picked for standardization by NIST, but NIST has yet to issue a FIPS document specifying and standardizing it.

wolfSSL’s perspective is that you should start your post-quantum migration journey today and use algorithms that are already standardized such as ML-KEM. That said, if anyone out there wants to take HQC for a spin, please let us know!! As always, wolfSSL is a customer driven organization and when we hear enough interest, we will make it happen!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Hello there! You! We know you are out there. You learned about Hamming codes in college or university, and maybe even use them in your professional career in consumer electronics or telecommunications. Now you are wondering how simple error correcting codes can be transformed into a KEM (Key Encapsulation Mechanism) for doing secure key transport. To you, we present the quantum-safe HQC (Hamming Quasi-Cyclic) KEM.

Are you hoping to see a professional production level implementation of HQC KEM? You are in luck. We want to make one! Make sure to register your interest in a wolfCrypt implementation of HQC KEM by sending a feature request for it to facts@wolfssl.com.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

ML-KEM (Module Lattice Key Encapsulation Mechanism) is for secure key exchange. ML-KEM enables two parties to establish a shared secret key over an insecure channel.

ML-DSA (Module Lattice Digital Signature Algorithm) is for authentication. ML-DSA allows a signer to generate a digital signature that can be verified by others, ensuring the authenticity and integrity of a message.

Both ML-KEM and ML-DSA are public key algorithms; that is to say, both have a key generation operation that generates a public key and private key.

For ML-KEM, an encapsulation operation uses the public key to generate a secret and ciphertext. The decapsulation operation uses the private key and ciphertext to get the same secret.

For ML-DSA, the private key and a message are used to generate a signature. The public key, message, and signature are used in an operation to verify that the signature of the message was generated by the corresponding private key.

The most important thing they have in common is that they are both post-quantum algorithms that have already been standardized by NIST and can be used TODAY!

In summary, ML-KEM and ML-DSA serve different purposes in cryptography, with ML-KEM focused on secure key transport and ML-DSA focused on digital signatures and authentication, but both protecting against a CRQC (Cryptographically Relevant Quantum Computer).

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL is excited to announce upcoming support for the Leighton-Micali Signature (LMS) scheme in wolfPKCS11. This implementation builds upon our existing LMS support in wolfCrypt to provide a complete PKCS#11 API interface for LMS operations.

LMS, a stateful hash-based signature scheme standardized in RFC 8554 and approved by NIST SP 800-208, is already incorporated into the latest version of the PKCS#11 specification. This quantum-resistant signature scheme is designed to be resistant to attacks from quantum computers and is best used in off-line signing operations such as firmware signing.

The addition of LMS support to wolfPKCS11 will enable applications using the PKCS#11 interface to leverage wolfSSL’s proven LMS implementation.

Key Features:

• Complete PKCS#11 API support for LMS operations
• Quantum-resistant stateful hash based signature scheme
• Compliant with NIST SP 800-208 specifications

This enhancement demonstrates wolfSSL’s continued commitment to providing comprehensive support for post-quantum cryptography across our product line.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now