ML-KEM vs ML-DSA vs SLH-DSA: Which Is Best for Post-Quantum Signatures?

Quick Introductions

RSA and ECC are geared toward the day quantum computers arrive, and the industry is trying to get ahead of the curve. NIST has adopted three algorithms for key establishment (ML-KEM), ML-DSA, and SLH-DSA for signatures.

NIST has recently completed three post-quantum standards that will help keep systems secure when quantum computers can break RSA/ECS encryption. ML-KEM is used for setting up shared secrets via key encapsulation and is not a signature algorithm.

Both ML-DSA and SLH-DSA provide digital signatures, but they handle specific needs in a different manner. ML-DSA is a generic-purpose signature default, good for most protocols and applications, with relatively small signatures and fast operations.

SLH-DSA is a conservative alternative with only the security of hash functions assumed, with mathematical diversity should lattice-based hardness assumptions ever fail. The trade-off between speed, size, and algorithm variety is between smaller and faster ML-DSA and larger and slower signatures, and slower verification, for SLH-DSA.

Key Takeaways

• NIST has adopted ML-KEM for key establishment, and ML-DSA and SLH-DSA for signatures. The only two signature schemes that are relevant to authentication are. Here you’ll learn how to do that and which of them to use for your deployment.
• The primary method of encapsulation for creating shared secrets used in TLS handshakes, VPN tunnels, and other key exchange methods is called ML-KEM (FIPS 203). It is not meant for digital signatures, and it replaces classical key transport methods.
• With its impressive suite of performance and size benefits, ML-DSA (FIPS 204) is the canonical general-purpose lattice-based digital signature algorithm and is used for a wide variety of use cases from certificates to code signing, to firmware updates, and to most common types of signatures.
• SLH-DSA (FIPS 205) is the stateless hash-based algorithm that results in larger-sized signatures and is a bit slower. It is chosen by organisations that need conservative security assumptions using just hash functions, or that wish to be protected from lattice cryptanalysis by using multiple algorithms.
• Most teams should implement ML-DSA first and keep SLH-DSA as a backup in high-assurance environments where the differing underlying concepts of cryptography are important.

Today’s Public-Key Cryptography is Running Out of Time

RSA and ECC Can Be Broken by Quantum Computers

Shor’s algorithm allows for the solution of these problems in the large-scale quantum computer model. The algorithm is able to factor large integers and to efficiently recover the private keys from public keys even in polynomial time for an attacker.

This can then be altered, and previously decrypted encrypted sessions can be redecrypted with public keys afterwards.

The present threat is the “harvest now, decrypt later” scheme. Sadly, adversaries already capture and store encrypted traffic and signed artefacts, and when quantum technology is in place, they’ll be able to decipher or spoof them.

The same match-up of long-lived certificates, software updates, and legal documents has the same needs – to remain trustworthy over a long period of time. It seems that teams that are not yet leveraging RSA or ECC should have a migration plan now before a first large quantum machine may appear.

Recommended: 460 Day Code Signing Certificate Validity: A New Era of Trust and Automation

Why NIST Introduced Post-Quantum Standards

In 2024, NIST completed a multi-year, multi-round PQCP standardisation process with researchers around the world, and identified and finalised 3 algorithms. The standards replace RSA and ECC with proven but already analysed alternative systems for organisations, not experimental ones.

They are the practical solution to the quantum threats and offer interoperable standard building blocks which vendors and standards can access. Planning for migration must begin now. Potential adversaries are already gathering encrypted data and long-lived signatures, and large-scale quantum computers may be available in another decade.

Recommended: PQC Code Signing in a CNSA 2.0 World: Preparing for the Quantum Leap

By deferring the transition, the systems continue to be vulnerable over the course of many years following the first quantum computer capable of performing cryptographically significant tasks.

By beginning the process of evaluation and testing of the new algorithms in the early stages, organisations will be able to undertake the migration with a minimum of disruption and risk.

Overview: The Three NIST PQC Standards

ML-KEM Explained

The module-lattice-based Key Encapsulation Mechanism is now known as ML-KEM (FIPS 203) and used to be called CRYSTALS-Kyber.

• It provides a shared secret between two people to be used for generating session keys in encrypted communication.
• It is utilised to replace RSA key transport and elliptic curve Diffie-Hellman in protocols like TLS, VPNs, and other key exchange situations.
• Unlike signature algorithms, in which the message as well as its accompanying signature is encrypted, ML-KEM does not produce or validate digital signatures, but it only uses keys for encryption.

ML-DSA Explained

• The module-lattice-based Digital Signature Algorithm (ML-DSA (FIPS 204)) is the old name of the CRYSTALS-Dilithium Digital Signature Algorithm.
• It is used as the common post-quantum signature scheme that supersedes RSA and ECDSA signature usage in certificates, code signing, and all typical types of authentication.
• As a result, in many practical deployments, ML-DSA generates smaller signatures and verifies them faster, compared to SLH-DSA.

SLH-DSA Explained

The previously used name of SLH-DSA (FIPS 205) was SPHINCS+.

It provides mathematical diversity, since it is based only on the strength of the hash function and not on lattice problems.

The algorithm yields larger signatures than ML-DSA, and signing is slower than in the latter. As a result, it is kept for scenarios with high assurance requirements or where organisations wish to have an alternative to lattice-based signatures from an independent authority.

ML-KEM vs ML-DSA vs SLH-DSA: Quick Comparison

The table below displays the three NIST standards for post-quantum cryptography, reviewed side by side. Keep in mind that ML-KEM is a fundamental encapsulation method and not a signature scheme, and that there are two signature schemes (ML-DSA and SLH-DSA).

Algorithm	FIPS	Type & Security Basis	Primary Use	Size / Speed	Best For
ML-KEM	203	KEM · Module lattice	Shared secrets (TLS, VPN, key exchange)	Small / Fast	Everyday key exchange (replaces ECDH & RSA transport)
ML-DSA	204	Signature · Module lattice	Certificates, code signing, authentication	Moderate / Fast	Most signature use cases (practical default)
SLH-DSA	205	Signature · Hash functions	High-assurance signatures & diversity	Large / Slow	Conservative or diversity-required scenarios

How to Choose the Right PQC Algorithm?

Use ML-KEM when you want a shared secret for data protection, or you want to exchange and update a secret key. It replaces classical approaches like ECDH and RSA key transport in TLS, VPNs, and more.

Use ML-DSA to create general-purpose digital certificates, code signing certificates, and certificates for documents or daily use. It has optimal performance and volume for most use cases.

Select SLH-DSA for signatures with high assurance based on different mathematical assumptions. It has a hash-based design for diversity if lattice-based schemes take any significant strides in the future.

If confidentiality and authenticity are needed for a protocol or system, use ML-KEM and ML-DSA together. In this pairing, secure key establishment and reliable signatures are handled within one stack, that is, the post-quantum stack.

For long-lived roots of trust or rarely-used signing operations with a requirement for algorithmic diversity, consider the use of SLH-DSA instead of ML-DSA. Most of the current systems remain at the ML-DSA baseline and only incorporate SLH-DSA when conservatism is needed.

Most Common Practical Choice

Most organisations will combine ML-KEM with ML-DSA for signatures, since this can provide acceptable performance, sizes, and address the majority of needs.

In TLS handshakes and in VPN tunnels, among other protocols that establish sessions, ML-KEM is an alternative to classical key agreement.

For certificates, code signing, document authentication, and routine authentication purposes, ML-DSA addresses the authentication side of the signature.

They are both combined to handle both confidentiality and authenticity, while not being as large or as slow as SLH-DSA. This combination is thus the tried and trusted hybrid of the mostly-at-risk stacks, RSA and ECC, for most systems that need an upgrade.

When SLH-DSA Makes Sense

• SLH-DSA is reasonable for root certificates, long-term archival signatures, or a situation that requires a variety of algorithms not available in lattice-based schemes.
• It draws its security from nothing but hash functions, making it an independent resource for the organisation in the event that lattice assumptions are found to be insecure.
• The relatively large signatures and slower signing time make it more suitable for changed and infrequent code signatures and signing large numbers of certificates.

For this reason, most teams will thus use ML-DSA as a default, and reserve SLH-DSA for occasional high assurance applications.

Common Mistakes and CNSA 2.0 Note

Among the common errors is the use of ML-KEM as a signature algorithm. It can only be used to encapsulate keys and is incapable of creating or verifying a digital signature.

CNSA 2.0 includes three National Security Systems: ML-KEM and ML-DSA, but not SLH-DSA. Most commercial deployments are similar in nature.

Going the hybrid way, algorithm agility is helpful in transition. Classical and post-quantum algorithms can be deployed simultaneously, ensuring systems remain protected in case classical algorithms are suddenly given a significant boost.

Conclusion

Migration toward Q-based attacks is definitely here, and it is true for both ECC and RSA. Resolutely use ML-KEM for key exchange, ML-DSA as the default signature method, and SLH-DSA only for certain highly trusted applications.

To provide organisations with a quantum-safe foundation, SignMyCode supports the appropriate algorithms for certificates and code signing.

Search