up:: In the Protocols MOC

wolfSSL

wolfSSL is a small-footprint TLS and cryptography library written in C for embedded systems, IoT devices, real-time operating systems, and other resource-constrained environments, built around the wolfCrypt cryptographic engine and supporting SSL 3.0 through TLS 1.3 and DTLS 1.3. It matters for the post-quantum transition because it carries native implementations of ML-KEM and ML-DSA (plus SLH-DSA and the stateful hash-based schemes) inside a library that fits in 20 to 100 kilobytes, which is exactly the class of hardware where a full-size library like OpenSSL does not fit, so it is one of the main routes to running the new algorithms on constrained devices where footprint and FIPS 140-3 validation both matter.

Source: wolfSSL, wolfSSL product page (footprint 20-100 kB, TLS 1.0-1.3 and DTLS support); wolfSSL, wolfCrypt Post-Quantum product page.

The short version:

• wolfSSL is a lightweight TLS library, and wolfCrypt is the cryptographic engine underneath it; the pair is built for embedded and IoT hardware, with a footprint of 20 to 100 kB and runtime memory of 1 to 36 kB, which wolfSSL describes as roughly 20 times smaller than OpenSSL.
• wolfCrypt carries native post-quantum implementations: ML-KEM (512, 768, 1024), ML-DSA (44, 65, 87), SLH-DSA (twelve parameter sets), and the stateful hash-based schemes LMS/HSS and XMSS/XMSS-MT.
• It dropped its earlier liboqs integration in favor of its own in-tree Kyber and Dilithium code, which is what lets the algorithms ship inside the small, self-contained library rather than pulling in a large external dependency.
• For TLS 1.3 it negotiates the hybrid groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, the same standardized groups the rest of the ecosystem uses.
• The FIPS distinction is load-bearing and different from a fully-validated stack: wolfCrypt holds completed FIPS 140-3 certificates (#4718 and #5041), but those are the classical module; the post-quantum FIPS 140-3 validation is in process, not yet complete, so the PQC algorithms are in the library while the validated PQC module is still pending.

Think of wolfSSL as a folding multi-tool where OpenSSL is a full workshop. Both cut, drive, and turn the same fasteners, and the workshop has more of everything, but only one of them fits in the pocket of a device the size of a coin. The post-quantum standards arrive as new, heavier attachments for that multi-tool, and the whole question for a tiny sensor or a smart card is whether the tool still fits in the pocket once those attachments are added. wolfSSL’s answer is to machine the attachments as compactly as possible and keep the tool small enough to stay where it already lives.

What is wolfSSL?

wolfSSL is a production TLS and cryptography library, formerly named CyaSSL, that is deliberately engineered for the smallest end of the hardware spectrum: microcontrollers, IoT endpoints, RTOS-based systems, and bare-metal firmware. It splits into two layers. wolfSSL is the TLS and DTLS layer that terminates connections and negotiates handshakes, and wolfCrypt is the underlying cryptographic engine that supplies the primitives, so “does wolfSSL support post-quantum key exchange” is really “does wolfCrypt carry the ML-KEM primitive, and does the wolfSSL TLS layer negotiate a group that uses it.” It supports SSL 3.0 and TLS 1.0 through 1.3, plus DTLS 1.0, 1.2, and 1.3, on the client and server side.

Source: wolfSSL, wolfSSL product page.

The reason it exists as a separate library from OpenSSL is size. wolfSSL states a minimum footprint of 20 to 100 kB depending on build options, runtime memory between 1 and 36 kB, and positions itself as roughly 20 times smaller than OpenSSL, which is why it turns up in firmware, secure elements, and consumer devices where a general-purpose library will not fit at all. That size discipline is the whole context for its post-quantum story: the new algorithms have to be added without breaking the property that makes the library useful in the first place.

Source: wolfSSL, wolfSSL product page (20-100 kB footprint, 1-36 kB runtime, “20x smaller than OpenSSL”).

Which post-quantum algorithms does wolfSSL support?

wolfCrypt carries native implementations of the full NIST post-quantum lineup for key establishment and signatures, plus the two stateful hash-based schemes that CNSA 2.0 calls for. The support is broad, and the important part is that it is all in-tree, so a constrained build pulls in only wolfCrypt rather than wolfCrypt plus a large external PQC library.

Family	Algorithm and parameter sets	Role
Key establishment	ML-KEM 512, 768, 1024	Quantum-safe key encapsulation; ML-KEM-1024 is the CNSA 2.0 set
Signatures (lattice)	ML-DSA 44, 65, 87	General-purpose signatures; ML-DSA-87 is the CNSA 2.0 set
Signatures (hash-based)	SLH-DSA, twelve parameter sets (SHAKE and SHA2, small and fast)	Conservative stateless hash-based signatures
Signatures (stateful hash-based)	LMS/HSS (RFC 8554), XMSS/XMSS-MT (RFC 8391)	CNSA 2.0-approved for firmware and code signing

Source: wolfSSL, wolfCrypt Post-Quantum product page (ML-KEM 512/768/1024, ML-DSA 44/65/87, SLH-DSA twelve parameter sets, LMS/HSS per RFC 8554, XMSS/XMSS-MT per RFC 8391).

Two details are worth teaching. The first is the naming: the wolfSSL build options are still --enable-kyber and --enable-dilithium (or --enable-mlkem), because Kyber and Dilithium are the pre-standardization names for what NIST finalized as ML-KEM and ML-DSA, so the same code answers to both names. The second is the stateful hash-based inclusion. LMS/HSS and XMSS are not in the main FIPS 203/204/205 set, and they matter specifically for the constrained world because they are the NSA CNSA 2.0-approved choice for signing firmware and software, which is a role a small device’s secure boot chain needs.

Source: wolfSSL, deprecation notice for the liboqs integration (native Kyber and Dilithium, --enable-kyber --enable-dilithium).

Why did wolfSSL drop the liboqs integration?

wolfSSL retired its liboqs integration because it had built its own in-tree implementations of the same algorithms, and dropping the external dependency reduced the codebase it had to maintain. Its notice states plainly that “the wolfSSL library already provides its own implementations of post-quantum algorithms, including Kyber and Dilithium,” and that removing the liboqs path was “intended to simplify the maintenance of the wolfSSL codebase by reducing the line count.” The --with-liboqs configure option goes away, and the native --enable-kyber and --enable-dilithium options take its place.

Source: wolfSSL, deprecation notice for the liboqs integration (notice posted 2025-02-05).

This is a meaningful engineering move for the constrained-device case, not a footnote. liboqs is the industry’s PQC reference library, and its own maintainers advise against using it to guard sensitive data in production, so a library that wants a validated, production-grade footprint has a reason to own its implementation rather than link a research reference. Owning the code in-tree also keeps the library self-contained, which is what preserves the small footprint: a 20-kilobyte library cannot afford to pull in a large external dependency to get one algorithm.

Source: liboqs repository, github.com/open-quantum-safe/liboqs (maintainers advise against production use).

Why does wolfSSL’s small footprint matter for post-quantum on constrained devices?

Because the binding limit for post-quantum on small hardware is size, and wolfSSL is built to conserve exactly the budgets the new algorithms strain. The core problem of constrained-device PQC is that post-quantum keys and signatures are far larger than the elliptic-curve artifacts they replace, so on a device with tens of kilobytes of RAM the algorithm has to fit alongside the library that runs it. A TLS library that is itself 20 to 100 kB, rather than several hundred, leaves more of that scarce memory for the cryptographic work.

Source: wolfSSL, wolfSSL product page (20-100 kB footprint, 1-36 kB runtime memory).

The library also carries architecture-specific assembly for the processors these devices actually use, which is where the footprint story meets the performance story:

1. Assembly for the constrained targets. wolfCrypt’s post-quantum code is performance-optimized with assembly routines for x86_64, ARM, and RISC-V, which wolfSSL positions as suited to embedded systems with a small footprint or bare-metal deployment.
2. The math is rarely the blocker. On the microcontrollers these devices use, the lattice schemes are competitive with or faster than the elliptic-curve code they replace, so a well-tuned small library removes the size objection without introducing a speed one. The remaining constraint is memory and bandwidth, which is a footprint discipline problem, and that is the property wolfSSL is designed around.
3. It reaches the smallest secure hardware. wolfSSL reports its firmware TPM as among the first firmware TPMs with post-quantum cryptography, running ML-DSA and ML-KEM on targets like a Cortex-M33 bare-metal core and STM32 secure enclaves, which is about as constrained as a cryptographic environment gets.

Source: wolfSSL, wolfCrypt Post-Quantum product page (assembly for x86_64, ARM, RISC-V; embedded small-footprint and bare-metal); wolfSSL, The First Firmware TPM with Post-Quantum Cryptography.

The framing to hold onto is that footprint is not a nice-to-have here, it is the whole game. On a server the choice of TLS library is about features and ecosystem; on a coin-sized secure element it is about what physically fits, and that is the specific gap wolfSSL is built to fill.

Is wolfSSL’s post-quantum support FIPS 140-3 validated?

Not yet, and the distinction is the single most important fact to get right about wolfSSL’s post-quantum posture. wolfCrypt holds completed FIPS 140-3 validations, certificate #4718 (which wolfSSL describes as the industry’s first under SP 800-140Br1) and certificate #5041 (effective through July 2030), but those are the classical cryptographic module and do not include the post-quantum algorithms. The post-quantum FIPS 140-3 validation is a separate, later certification that is in process, with the formal CMVP submission underway, so the PQC algorithms are present and usable in the library today while the validated post-quantum module is still pending.

Sources: wolfSSL, wolfSSL Advances FIPS Leadership with New Certificate #5041 (certs #4718 and #5041; PQC FIPS a separate future certification); wolfSSL, wolfCrypt FIPS 140-3 with Post-Quantum Cryptography Available Now (formal CMVP submission in process; initial PQC-enabled FIPS configurations available for evaluation).

This is the same shape of gap that trips people up with OpenSSL, whose code has done post-quantum TLS since 3.5 while its validated module lags behind, and it is why a regulated deployment tracks two separate dates. One nuance that regulators care about: a CAVP-tested algorithm is not the same thing as a CMVP-validated module. CAVP validates an algorithm implementation in isolation, and CMVP validates the whole cryptographic module that ships it, so a compliance gate turns on the module certificate. Until wolfCrypt’s post-quantum module completes CMVP validation, a FIPS-bound estate treats wolfSSL’s PQC as available for integration and evaluation rather than as a validated compliance answer.

The contrast with AWS-LC is instructive, and both facts are true at once. AWS-LC already carries a completed FIPS 140-3 validation that includes ML-KEM, which suits a validated cloud or server deployment, while wolfSSL’s completed FIPS modules are still classical and its PQC validation is pending, which is the honest state of the smallest-footprint option. The library you reach for depends on whether your binding constraint is a completed PQC validation today or fitting the algorithm onto hardware AWS-LC was never sized for.

How does wolfSSL do post-quantum TLS 1.3?

wolfSSL goes post-quantum in TLS 1.3 the same way the rest of the ecosystem does, by negotiating a hybrid key-exchange group that pairs a classical elliptic-curve exchange with ML-KEM, so the session key is derived from both and stays secure as long as either half holds. The standardized groups it supports are the ones a modern client and server will actually negotiate:

1. X25519MLKEM768, pairing classical X25519 with ML-KEM-768, which carries most real post-quantum TLS traffic.
2. SecP256r1MLKEM768 and SecP384r1MLKEM1024, the NIST P-curve variants for stacks that must standardize on those curves, most often under a profile like CNSA 2.0.

Source: wolfSSL, wolfSSL Manual, Appendix G, supported groups (standard hybrid groups X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024; experimental and legacy Kyber Round 3 groups behind build options).

The library also keeps a set of experimental hybrid groups and the older Round 3 Kyber groups (P256_KYBER_LEVEL1 and its siblings) behind separate build options, which matters for a specific migration hazard on long-lived devices. A device that shipped speaking a pre-standard Kyber group needs to move to the standardized ML-KEM groups, and on fixed firmware that can be a hardware problem rather than a config change, which is the crypto-agility constraint that makes constrained deployments the hard part of the whole transition. wolfSSL states its CNSA 2.0-aligned support, which it calls itself the world’s first cryptography provider to offer, covers ML-KEM-1024, ML-DSA-87, LMS, and XMSS; the “world’s first” framing is wolfSSL’s own claim rather than an independently audited fact, so the qualified reading is the one to trust.

Source: wolfSSL, wolfCrypt Post-Quantum product page (CNSA 2.0 support: ML-KEM-1024, ML-DSA-87, LMS, XMSS).

Where does wolfSSL’s post-quantum stack deploy?

wolfSSL’s post-quantum support ships through the family of products built on the same wolfCrypt engine, so the deployment surface is the embedded and IoT stack rather than the data center. When wolfCrypt gains an algorithm, the products that link it inherit the capability, which is what makes the footprint discipline compound across a whole device.

1. wolfBoot is the secure boot loader, and it is where the stateful hash-based signatures (LMS/HSS, XMSS) and ML-DSA verify firmware images, which is the first signing surface a device needs to migrate because a firmware root of trust is long-lived.
2. wolfSSH, wolfMQTT, wolfTPM, and wolfHSM carry the primitives into SSH, MQTT messaging, the trusted platform module, and the hardware security module layers of an embedded system.
3. Mainstream software links it too: wolfSSL reports post-quantum support available through curl, the Apache and Nginx web servers, Lighttpd, Stunnel, and toolchains like STM32CubeIDE and the NXP Application Code Hub.

Source: wolfSSL, wolfCrypt Post-Quantum product page (integrations across wolfBoot, wolfMQTT, wolfSSH, wolfHSM, wolfTPM, curl, Apache, Nginx, Lighttpd, Stunnel, STM32CubeIDE, NXP Application Code Hub).

When should a developer reach for wolfSSL?

Reach for wolfSSL when the target is small, the deployment is embedded or IoT, or the crypto has to live in firmware or a secure element where a general-purpose library will not fit. The decision usually resolves along a few concrete lines:

1. The hardware is constrained. On a microcontroller, secure element, or bare-metal firmware image with tens of kilobytes of memory, wolfSSL’s 20-to-100-kB footprint is the property that makes post-quantum feasible at all, which is a fit a larger library cannot offer regardless of features.
2. You need PQC in the boot chain. wolfBoot with LMS/XMSS or ML-DSA is a direct path to signing and verifying firmware with quantum-safe signatures, which a device with a long field life needs before its classical signing key becomes a liability.
3. You want breadth of post-quantum algorithms in one small library. wolfCrypt carries ML-KEM, ML-DSA, SLH-DSA, and the stateful hash-based schemes natively, so a device can pick the family that fits its memory and bandwidth without pulling in separate dependencies.
4. You can accept that PQC FIPS validation is pending. If your gate is a completed post-quantum FIPS 140-3 module today, AWS-LC’s validated ML-KEM is the current answer; if your gate is fitting the algorithm onto small hardware and you can evaluate against a pending validation, wolfSSL is the fit.

The counter-case is a server or cloud deployment where footprint is a non-issue and a completed PQC validation is required now, where AWS-LC or OpenSSL 3.5’s native ML-KEM anchors the stack more naturally. wolfSSL’s edge is specifically the small end of the hardware spectrum, which is also the hardest part of the migration to reach.

Common misconceptions

1. “wolfSSL’s post-quantum crypto is FIPS 140-3 validated.” The completed wolfCrypt FIPS 140-3 modules (#4718, #5041) are the classical module and do not include the post-quantum algorithms. The PQC FIPS 140-3 validation is a separate certification still in process, so the algorithms are usable in the library while the validated PQC module is pending.
2. “wolfSSL and wolfCrypt are the same thing.” wolfCrypt is the low-level cryptographic engine that supplies primitives like ML-KEM and ML-DSA; wolfSSL is the TLS and DTLS layer that links wolfCrypt and negotiates connections. The TLS layer decides whether a post-quantum group is actually used.
3. “wolfSSL still depends on liboqs for post-quantum support.” It moved to its own in-tree Kyber and Dilithium implementations and deprecated the liboqs integration in 2025, which is what keeps the algorithms inside the small self-contained library.
4. “Kyber and ML-KEM are two different algorithms wolfSSL supports.” They are the same algorithm at different stages of standardization. Kyber and Dilithium are the pre-standard names for what NIST finalized as ML-KEM and ML-DSA, and the wolfSSL build options reflect the older names.
5. “Post-quantum is too big to run on the tiny devices wolfSSL targets.” The lattice key exchange fits comfortably, and the speed is competitive on 32-bit parts. The genuine strain is the large signatures and the memory to hold them, which is a footprint problem wolfSSL’s size is built to help with rather than a reason it cannot run.

Questions people ask

Is wolfSSL’s ML-KEM FIPS 140-3 validated? Not yet. wolfCrypt holds completed FIPS 140-3 certificates (#4718 and #5041), but those are the classical module. The post-quantum FIPS 140-3 validation, covering ML-KEM, ML-DSA, and the stateful hash-based schemes, is in process with the CMVP submission underway, so a regulated deployment treats wolfSSL’s PQC as available for integration and evaluation rather than as a validated compliance answer today.

What’s the difference between wolfSSL and wolfCrypt? wolfCrypt is the cryptographic engine that implements the primitives, including the post-quantum algorithms. wolfSSL is the TLS and DTLS library built on top of it that terminates connections and negotiates handshakes, including choosing whether to advertise a post-quantum hybrid group.

How small is wolfSSL? wolfSSL reports a footprint of 20 to 100 kB depending on build options, runtime memory of 1 to 36 kB, and describes itself as roughly 20 times smaller than OpenSSL, which is why it fits on microcontrollers and secure elements where a general-purpose library will not.

Which hybrid group does wolfSSL negotiate for TLS 1.3? The standardized groups are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, the same set the wider ecosystem uses. It also keeps experimental groups and the legacy Round 3 Kyber groups behind separate build options.

Does wolfSSL support the stateful hash-based signatures? Yes. It carries LMS/HSS (RFC 8554) and XMSS/XMSS-MT (RFC 8391), which are the CNSA 2.0-approved choice for signing firmware and software, and it exposes them through wolfBoot for secure boot on embedded devices.

Can I sign firmware with post-quantum signatures using wolfSSL? Yes. wolfBoot, the wolfSSL secure boot loader, verifies firmware images with LMS/XMSS or ML-DSA, which is the migration a long-lived device needs early because a firmware root of trust outlives most of the rest of the estate.

Should I use wolfSSL or AWS-LC for post-quantum? It depends on the binding constraint. For a completed FIPS 140-3 validation that includes ML-KEM today, AWS-LC is the current answer. For fitting post-quantum onto constrained embedded or IoT hardware where footprint is the limit, wolfSSL is built for that end of the spectrum and its PQC validation is still pending.

Do Kyber and Dilithium still work, or do I need ML-KEM and ML-DSA? They are the same algorithms. The wolfSSL build options --enable-kyber and --enable-dilithium (and --enable-mlkem) enable what NIST standardized as ML-KEM and ML-DSA, so existing configurations keep working under the newer names.

---

Everything here is the map, given freely. When your team needs its own fleet of embedded and IoT devices inventoried, its post-quantum algorithms sized to the memory each part actually has, and the FIPS-validation timeline tracked against your compliance gate, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.