NIST PQC Algorithms for PKI Engineers: ML-KEM, ML-DSA, SLH-DSA

NIST finalized ML-KEM, ML-DSA, and SLH-DSA (FIPS 203–205); OpenSSL 3.5 ships native implementations. This page is the sizes-and-commands layer for PKI engineers—paired with hybrid certificates and cryptographic primitives.

NIST PQC Algorithms for PKI Engineers: ML-KEM, ML-DSA, SLH-DSA

TL;DR: ML-KEM secures key establishment (TLS KEM; default hybrid X25519MLKEM768 in OpenSSL 3.5); ML-DSA is the practical signature choice for certs; SLH-DSA is a conservative hash-based option with huge signatures—CNSA 2.0 centers on ML-KEM + ML-DSA, not SLH-DSA.

Why This Matters

Executives: PQC is a timeline and compliance topic (e.g. CNSA 2.0, vendor roadmaps)—wrong algorithm choice wastes budget on non-approved or unusable designs.

Security: “Harvest now, decrypt later” makes ML-KEM in TLS the near-term priority; certificate authentication shifts later as clients catch up.

Engineers: Signature and KEM sizes change handshake bandwidth, HSM throughput, and monitoring—decisions must be evidence-based.

Problem Statement

• ML-DSA signatures are orders of magnitude larger than ECDSA—tools and MTU assumptions break silently.
• SLH-DSA is seductive for “hash-only trust” but impractical for busy TLS leaf certs.
• OpenSSL version drift: pre-3.5 needs oqs-provider for many PQC algorithms.
• CNSA 2.0 excludes SLH-DSA; NSS workstreams need ML-KEM-1024 / ML-DSA-87 for highest tier.
• FN-DSA (Falcon) / FIPS 206 still in motion—don’t bet production on it yet.

Algorithm overview

FIPS 203: ML-KEM

Module-lattice KEM (not a classical NIKE). Parameter sets:

Variant	Level (rough)	Public key	Ciphertext	Shared secret
ML-KEM-512	~AES-128	800 B	768 B	32 B
ML-KEM-768	~AES-192	1,184 B	1,088 B	32 B
ML-KEM-1024	~AES-256	1,568 B	1,568 B	32 B

TLS: ML-KEM replaces the KEM portion of 1.3 key establishment; X25519MLKEM768 is the common hybrid construction (classical + PQC).

FIPS 204: ML-DSA

Lattice signatures—successor use case for RSA/ECDSA in many designs.

Variant	Level	Public key	Signature	Notes
ML-DSA-44	2	1,312 B	2,420 B	Not in CNSA 2.0
ML-DSA-65	3	1,952 B	3,309 B	General-purpose default
ML-DSA-87	5	2,592 B	4,627 B	CNSA high tier

FIPS 204 includes HashML-DSA and context string semantics—draft-era artifacts may not interoperate with final FIPS.

FIPS 205: SLH-DSA (SPHINCS+)

Security from hash assumptions; many parameter sets (“f” fast/large vs “s” smaller/slower). Example: SLH-DSA-SHA2-128f signature ~17 KiB—larger than many whole chains today.

PKI role: roots / rare signing / firmware more than busy TLS leaves. Not in CNSA 2.0; stateful LMS/XMSS (SP 800-208) used where stateful hash is required in that suite.

OpenSSL 3.5 usage

OpenSSL 3.5 (LTS to ~2030) includes ML-KEM, ML-DSA, SLH-DSA in the default provider.

# ML-DSA-65 key
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_key.pem
openssl pkey -in mldsa65_key.pem -pubout -out mldsa65_pub.pem
openssl pkey -in mldsa65_key.pem -text -noout

# Self-signed cert (example; use your CSR flow in production)
openssl req -x509 -new -key mldsa87_key.pem \
  -out mldsa87_cert.pem -days 365 \
  -subj "/CN=pqc-test.example/O=Org"

# TLS 1.3 test with hybrid KEM
openssl s_server -cert mldsa65_cert.pem -key mldsa65_key.pem \
  -tls1_3 -groups X25519MLKEM768 -accept 4433
openssl s_client -connect localhost:4433 -tls1_3 -groups X25519MLKEM768 -brief

List algorithms:

openssl list -signature-algorithms
openssl list -kem-algorithms
openssl list -tls-signature-algorithms

oqs-provider (pre-3.5 OpenSSL)

oqs-provider supplies algorithms through the provider interface; recent versions defer to OpenSSL 3.5 for algorithms native upstream.

openssl list -signature-algorithms -provider oqsprovider
openssl list -kem-algorithms -provider oqsprovider

Selection framework

Use case	Guidance
TLS KEM now	X25519MLKEM768 (hybrid ML-KEM-768)
TLS auth (transition)	Classical ECDSA certs + hybrid KEM until client PQC sig maturity; see hybrid PQC certificates
End-entity signing (lab/prod roadmap)	ML-DSA-65 general; ML-DSA-87 for CNSA-style high level
Root / rare sign	ML-DSA-87; optional SLH-DSA for diversity vs lattice-only
Code / firmware signing	ML-DSA-87 often fits (size less critical than TLS)
US NSS / CNSA 2.0	ML-KEM-1024, ML-DSA-87; follow NSA published transition dates

Size and performance summary

• Hybrid ClientHello overhead vs X25519 alone: on the order of ~1.2 KiB extra for X25519MLKEM768—usually bandwidth-limited, not CPU-limited, on modern servers.
• Three-cert chain signatures: ECDSA P-256 ~192 B sig material total vs ML-DSA-65 ~9.9 KiB—plan for handshake and cert-transport limits (IoT, satellite).
• SLH-DSA “f” variants: tens of KiB per signature—not default TLS leaf choice.

FN-DSA (Falcon) / FIPS 206

Still in development; implementation complexity (floating-point, sampling) slowed standardization. Not CNSA 2.0 today—track for future smaller-than-ML-DSA scenarios if standardized cleanly.

Operational checklist

• OpenSSL (or lib) version recorded; 3.5+ vs oqs-provider path documented
• Handshake size benchmarked on worst client path (mobile, remote)
• CNSA / NSS requirements mapped to ML-KEM-1024 / ML-DSA-87 where applicable
• HSM / KMS roadmap checked for ML-DSA and hybrid TLS at required TPS
• Lab tests for chain upload to CDNs/LBs with large certs

Related documentation

• Hybrid PQC certificates — composite vs catalyst, tooling, TLS testing
• Cryptographic primitives — classical baseline
• TLS protocol — handshake context
• X.509 standard — certificate structure
• Public and private key pairs
• Key management best practices
• Private key protection
• Threat models and attack vectors
• Certificate lifecycle management