Choose Your Algorithm

TL;DR — Default Picks

If you don't have special constraints, use these defaults. They match NIST Category 3 and are what most of the reference services in this portal use.

Task	Use this	Why
Digital signatures (general)	`ML-DSA-65`	FIPS 204, Cat 3, 3.3KB sig — good balance of security and size
Key establishment / TLS	`ML-KEM-768` (or hybrid `X25519MLKEM768`)	FIPS 203, Cat 3, 1.1KB ciphertext — hybrid for TLS interop
Long-lived signatures (firmware, archives)	`SLH-DSA-SHA2-256s`	FIPS 205, hash-based, most conservative security assumptions
Bandwidth-constrained (IoT, blockchain)	`ML-DSA-44` + `ML-KEM-512`	Smallest PQC options that still meet NIST Cat 2
Highest security (TOP SECRET, long horizon)	`ML-DSA-87` + `ML-KEM-1024`	NIST Cat 5 — matches AES-256 classical security

Decision Tree

Walk down from the top. Each branch takes about 30 seconds.

Q1. Do you need signatures, key establishment, or both?

→ Signatures only (code signing, JWT, document signing) → go to Q2

→ Key establishment / encryption (TLS, email encryption, messaging) → go to Q3

→ Both (most apps: REST API w/ JWT + TLS) → run Q2 and Q3 independently

Q2. Signatures — how long must they remain verifiable?

→ < 5 years (API tokens, session tickets, CI artifacts): ML-DSA-65

→ 5–20 years (contracts, TLS certs, released software): ML-DSA-65 or ML-DSA-87 if high-value

→ 20+ years / archival (firmware, legal records, root CAs): SLH-DSA-SHA2-256s — hash-based is the most conservative bet against future lattice breaks

→ Size-critical (blockchain tx, CoAP, LoRaWAN): ML-DSA-44 (2.4KB sig) — accept Cat 2 security

Q3. Key establishment — what's the transport?

→ TLS 1.3 (web/API traffic): X25519MLKEM768 hybrid — interop with non-PQC clients, defense-in-depth during migration

→ Application-layer (S/MIME, MLS, custom): ML-KEM-768 standalone

→ High-throughput / low-latency (VPN data plane): ML-KEM-512

→ Highest security: ML-KEM-1024

Q4. Are you in a regulated migration window?

→ Yes, still accepting classical verifiers: use dual-signature (ECDSA + ML-DSA-65) — both sigs validated, old clients verify ECDSA, new clients verify both. See dApp service for the pattern.

→ No, PQC-only greenfield: skip dual-sign; use ML-DSA-65 directly.

Full Algorithm Comparison

All algorithms are available from the Qudo provider. Sizes are exact; latencies are indicative (apple-silicon M-class, single-thread). Run Benchmark on your own hardware for authoritative numbers.

Signatures

Algorithm	NIST Level	Pub key	Priv key	Signature	Sign latency	Verify latency	Best for
`ML-DSA-44` FIPS 204	2	1.3KB	2.5KB	2.4KB	~0.3ms	~0.1ms	Bandwidth-sensitive: IoT, blockchain tx, constrained links
`ML-DSA-65` Default	3	2.0KB	4.0KB	3.3KB	~0.5ms	~0.2ms	General-purpose: JWT, API auth, code signing, TLS certs
`ML-DSA-87`	5	2.6KB	4.9KB	4.6KB	~0.8ms	~0.3ms	Highest classical-PQC security: TOP SECRET, long-horizon PKI roots
`SLH-DSA-SHA2-128s` FIPS 205	1	32B	64B	7.9KB	~3s	~2ms	Tiny keys, slow sign, archival integrity
`SLH-DSA-SHA2-128f`	1	32B	64B	17KB	~140ms	~7ms	Fast variant of 128s — 4× the sig size, 20× faster sign
`SLH-DSA-SHA2-256s` Conservative	5	64B	128B	29KB	~25s	~4ms	Highest-trust archival: firmware, root CA, offline signers. Hash-based — relies only on SHA-2, no lattice assumption
`SLH-DSA-SHA2-256f`	5	64B	128B	49KB	~400ms	~15ms	Fast 256-bit hash-based — usable online at the cost of 49KB sigs

Key Encapsulation (KEM)

Algorithm	NIST Level	Pub key	Priv key	Ciphertext	Encap latency	Decap latency	Best for
`ML-KEM-512` FIPS 203	1	0.8KB	1.6KB	0.8KB	~0.05ms	~0.05ms	High-throughput VPN data plane, constrained links
`ML-KEM-768` Default	3	1.2KB	2.4KB	1.1KB	~0.08ms	~0.08ms	TLS, S/MIME, messaging, general key establishment
`ML-KEM-1024`	5	1.6KB	3.2KB	1.6KB	~0.12ms	~0.12ms	Highest security: TOP SECRET, quantum-resistant VPN
`X25519MLKEM768` TLS default	3 + classical	1.2KB	2.4KB	1.2KB	~0.2ms	~0.2ms	TLS 1.3 hybrid — interop with non-PQC clients; defense-in-depth during migration

When to use SLH-DSA over ML-DSA

ML-DSA is the default for nearly every use case. Reach for SLH-DSA only when these apply:

Archival / long-horizon integrity

Firmware signatures that must verify decades from now, legal archives, root-CA certificates with 20+ year validity. Why: SLH-DSA's security rests only on SHA-2 preimage resistance — no lattice, no structured hardness. If a future cryptanalytic break ever affects ML-DSA, SLH-DSA remains a fallback.

Conservative / regulated environments

CNSA 2.0 suite (US NSA) currently lists SLH-DSA as the sole signature algorithm for the highest tier. If you're building for that regulatory boundary, SLH-DSA is mandated. Otherwise, ML-DSA-65 is fine.

Tiny key storage with rare signing

SLH-DSA keys are 32–128 bytes — ML-DSA keys are 2–5 KB. If you're embedding a verification key in firmware or a smart card, SLH-DSA public keys are 60× smaller. But sigs are ~10× larger, so it's only a win if sigs are produced rarely.

Don't use SLH-DSA for

JWTs, per-request API auth, TLS handshakes, blockchain tx, anything high-throughput. 29KB signatures and multi-second sign times make it unsuitable for interactive flows.

Migration Pattern: Dual-Signature (ECDSA + ML-DSA-65)

Use this when you must keep accepting classical-only verifiers during a transition window.

How it works: the signer produces both an ECDSA signature and an ML-DSA-65 signature over the same payload. Verifiers check whichever algorithms they support:

Legacy clients (classical-only): verify ECDSA, ignore the ML-DSA slot — backwards compatible.
Modern clients: verify both. A payload is trusted only if ECDSA and ML-DSA agree.
Quantum-adversary scenario: even if ECDSA breaks, the ML-DSA sig still vouches for the payload.

Trade-off: sigs are larger (ECDSA ~70B + ML-DSA 3.3KB ≈ 3.4KB total) and signing/verifying costs double. See the dApp service for a worked example.

Common Use Cases — What the Portal Services Use

REST API + JWT

ML-DSA-65 for JWT signing; X25519MLKEM768 for TLS. Short-lived tokens (1h), so pub-key rotation is cheap. → REST API migration

Email (S/MIME)

ML-KEM-768 + AES-256-GCM for content encryption, ML-DSA-65 for signing (sign-then-encrypt). → Email migration

IoT / constrained devices

ML-DSA-44 + ML-KEM-512 over CoAP/COSE. Smaller wire format, still Cat 2. → IoT migration

Code signing / CI/CD release

ML-DSA-65 for fast release flow. Consider SLH-DSA-SHA2-256s if the artifact is firmware or has >10-year shelf life. → Signing migration

Blockchain / dApp

Dual-sig (ECDSA + ML-DSA-65) during the transition window, then drop ECDSA. Keep tx size tight: ML-DSA-44 if the chain is sig-size-sensitive. → dApp migration