Post-quantum cryptography (PQC) is not one algorithm or a single product decision. This guide compares ML-KEM, ML-DSA, and SLH-DSA by purpose, data size, performance, protocol fit, and migration trade-offs so security teams can map the right approach to key exchange, encryption, signatures, and long-lived data.
Overview
A sufficiently capable fault-tolerant quantum computer could threaten widely used public-key systems based on integer factorization and discrete logarithms. The practical concern is not only whether such a machine exists today. Sensitive data can be captured now and decrypted later, while public-key systems often appear in certificates, software updates, identity systems, APIs, VPNs, storage platforms, and embedded devices with long replacement cycles.
PQC algorithms are designed to resist attacks from both conventional and quantum computers. They do not replace every part of a cryptographic system. In most deployments, symmetric encryption, hashing, key management, access controls, and secure operational practices remain necessary. The main migration question is which post-quantum mechanism fits each public-key function.
- ML-KEM is a key-encapsulation mechanism (KEM). It helps two parties establish a shared secret that can then be used with symmetric encryption.
- ML-DSA is a digital-signature algorithm for authentication, integrity, certificates, and signing operations.
- SLH-DSA is also a digital-signature algorithm, based on hash functions rather than the lattice approach used by ML-DSA.
The most important distinction is simple: ML-KEM addresses key establishment, while ML-DSA and SLH-DSA address signatures. A signature algorithm is not a substitute for a KEM, and a KEM does not authenticate a message by itself.
How to compare options
Start with the cryptographic function, not the algorithm name. Inventory where public-key cryptography is used and record whether each use involves confidentiality, authentication, integrity, non-repudiation, or several of these properties. Also document the protocol, endpoint type, certificate constraints, bandwidth limits, hardware support, and expected data lifetime.
Five comparison criteria are especially useful:
- Security role: Confirm whether the option performs key establishment or signing. This immediately narrows the shortlist.
- Object sizes: PQC public keys, ciphertexts, and signatures can be larger than their traditional counterparts. Assess certificate chains, handshake messages, firmware images, database fields, and network links.
- Performance profile: Test key generation, encapsulation, decapsulation, signing, and verification separately. Server throughput and constrained-device latency may lead to different choices.
- Protocol fit: Check whether the relevant TLS, VPN, identity, code-signing, messaging, storage, or device-management stack can carry the new objects and negotiate them correctly.
- Implementation maturity: Review library maintenance, hardware acceleration, language bindings, test coverage, side-channel protections, interoperability results, and the vendor's upgrade process.
A useful migration plan also separates algorithm selection from deployment mode. A hybrid design can use a conventional mechanism and a post-quantum mechanism together during transition, provided the protocol and implementation define how both results are combined and authenticated. Hybrid operation may reduce transition risk, but it can increase message size, complexity, and testing requirements.
Feature-by-feature breakdown
| Algorithm | Primary purpose | Size and performance profile | Typical fit | Main trade-off |
|---|---|---|---|---|
| ML-KEM | Establishing shared encryption keys | Public keys and ciphertexts are larger than many traditional key-exchange objects; operations are generally structured for efficient software use. | Secure transport handshakes, VPNs, application protocols, and encrypted sessions | Requires protocol support and does not provide authentication on its own |
| ML-DSA | Digital signatures | Signatures and public keys are larger than familiar elliptic-curve signatures; signing and verification should be benchmarked in the target environment. | Certificates, software signing, document integrity, APIs, and identity systems | Signature size can affect certificates, logs, bandwidth, and storage |
| SLH-DSA | Hash-based digital signatures | Signature sizes and signing costs vary by parameter set; verification and security assumptions differ from lattice-based signatures. | Long-lived signing roots, conservative trust domains, and situations where algorithm diversity matters | Signatures can be substantially larger, and operational choices require careful parameter selection |
ML-KEM is the usual candidate to examine first for confidential sessions because it solves the key-establishment problem directly. ML-DSA is often the practical starting point for general-purpose signing where ecosystem support, throughput, and object size are important. SLH-DSA offers a different mathematical basis and can be valuable where conservative hash-based assumptions or algorithm diversity are priorities, but its size and performance profile may make it less convenient for high-volume signing.
Do not select an algorithm from a benchmark run alone. Measure complete workflows, including certificate validation, retries, key rotation, serialization, logging, and failure handling. For background on the wider quantum risk, see the quantum computing readiness checklist for enterprise security teams.
Best fit by scenario
Encrypted network sessions
Evaluate ML-KEM for the key-establishment portion of the protocol. Prioritize handshake size, latency, gateway capacity, and interoperability across clients, servers, proxies, and inspection systems. A hybrid mode may be appropriate during migration when supported and tested by the complete technology stack.
Software and firmware signing
Compare ML-DSA and SLH-DSA against the update system's signature-size limits, bootloader memory, verification time, rollback controls, and device replacement cycle. For constrained devices, a larger signature can affect transport, storage, and recovery procedures even when verification itself is acceptable.
Certificates and enterprise identity
Assess public-key and signature growth across the entire certificate chain rather than only the leaf certificate. Check directory schemas, token formats, certificate authorities, hardware security modules, endpoint agents, and external identity providers. A technically sound algorithm can still be a poor fit if an intermediary silently truncates or rejects larger objects.
Long-term document or archive signing
Focus on verification over many years, trusted timestamping, key archival, revocation, and the ability to validate signatures after software and algorithm updates. SLH-DSA may deserve consideration where hash-based diversity is important, while ML-DSA may be more convenient where signature volume and storage are dominant concerns.
Embedded and constrained systems
Test RAM, flash, code size, random-number generation, power consumption, and update logistics. Avoid assuming that a result from a server benchmark transfers to a sensor, industrial controller, or secure element. The right choice may depend as much on the device's replacement plan as on cryptographic performance.
When to revisit
PQC decisions should be treated as a maintained engineering program, not a one-time procurement exercise. Revisit the comparison when standards guidance changes, libraries add or remove support, protocol specifications evolve, major interoperability findings appear, or a vendor changes its implementation and upgrade policy. Review it at least annually for systems with long-lived data or long hardware lifecycles.
For an actionable review, keep an inventory with the system owner, cryptographic function, current algorithm, data lifetime, endpoint constraints, protocol dependencies, and migration status. Then:
- Classify systems by confidentiality lifetime and replacement difficulty.
- Prioritize public-key uses that protect long-lived secrets, software trust, or widely deployed identities.
- Build test deployments for ML-KEM, ML-DSA, and, where relevant, SLH-DSA.
- Test complete protocol paths, including legacy clients, certificate chains, proxies, and recovery processes.
- Record algorithm identifiers, parameter sets, library versions, and rollback procedures.
- Schedule a review after every material standards, platform, or vendor change.
There is no universal best post-quantum encryption algorithm. ML-KEM is aimed at key establishment; ML-DSA and SLH-DSA are aimed at signatures. The durable decision is the one that matches the cryptographic function, survives real protocol testing, and can be updated as the post-quantum ecosystem develops.
