wolfSSL now supports SLH-DSA (SPHINCS+, FIPS 205) across the whole stack: key generation and signing in wolfCrypt, certificate handling in the ASN.1 layer, and now entity authentication in the TLS 1.3 and DTLS 1.3 handshake. An SLH-DSA leaf key can sign the CertificateVerify message and an SLH-DSA peer certificate can verify one, for both server authentication and mutual authentication. All twelve parameter sets are wired up: the SHAKE and SHA2 hash families at 128/192/256, in both the f (fast) and s (small) variants. Builds are gated per parameter set, so a build only ever advertises the variants it can actually perform.
Alongside that, wolfSSL can now be built post-quantum only: ML-KEM key exchange with ML-DSA or SLH-DSA authentication, and RSA, ECC and DH all compiled out. That is the CNSA 2.0 posture called for by EO 14412, which we wrote about in Preparing for the White House EO 14412. The initial patches from that post are now upstream, together with the fixes needed to make such a configuration build cleanly and interoperate, including quantum-safe session ticket resumption.
Making large signatures work in practice
The interesting engineering here is not the algorithm, it is the size. SLH-DSA signatures run from roughly 7.8 KB at 128s to about 49 KB at 256f, and post-quantum certificates are large to match. Two handshake messages that comfortably fit in a single TLS record with classical keys now routinely do not: the Certificate message and the CertificateVerify message. Everything downstream of that has to behave.
- CertificateVerify is streamed. An oversized signature is sent one record at a time rather than buffered whole, keeping peak memory close to a single signature. This is algorithm neutral, so ML-DSA benefits too.
- Non-blocking sends resume correctly. A partially sent message picks up exactly where it left off and re-sends identical bytes, which is what the handshake transcript requires.
- The certificate chain send was fixed. A long-standing bug corrupted multi-record certificate chains on non-blocking sockets. Classical certificates were never large enough to trigger it; SLH-DSA ones hit it immediately.
- Memory footprint stays sane. Certificate buffers are now sized from what is actually compiled in rather than from the largest signature the library could ever produce, worth roughly 26 MB of static memory on a full post-quantum build.
New CI configurations cover post-quantum-only handshakes for both signature algorithms, the fragmented and single-record CertificateVerify paths, and the non-blocking resume cases in both directions.
Trying it
./configure --enable-slhdsa # all SHAKE parameter sets ./configure --enable-slhdsa=sha2 # SHA2 family ./configure --enable-slhdsa=128s,128f # specific parameter sets
And for a fully quantum-safe stack with no classical algorithms at all:
./configure --enable-mlkem --enable-slhdsa --enable-tls-mlkem-standalone \
--disable-rsa --disable-ecc --disable-dh
Swap –enable-slhdsa for –enable-mldsa if you prefer lattice-based authentication. TLS 1.3 is required for both and is on by default.
If you are planning a CNSA 2.0 migration, or want help sizing a post-quantum handshake for a constrained device, contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now