Implementing ML-DSA in a Modern PKI

As the threat of quantum computing looms over traditional encryption, the National Institute of Standards and Technology (NIST) has finalized the first set of post-quantum cryptography (PQC) standards to protect our digital infrastructure. Among these, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), standardized in FIPS 204, stands out as the primary successor for general-purpose digital signatures.

The NIST PQC Selection

In August 2024, NIST released three final standards:

• FIPS 203 (ML-KEM): For key encapsulation (formerly CRYSTALS-Kyber).

• FIPS 204 (ML-DSA): For digital signatures (formerly CRYSTALS-Dilithium).

• FIPS 205 (SLH-DSA): A stateless hash-based signature scheme.

While SLH-DSA provides a robust "hash-only" backup, its performance overhead makes ML-DSA the preferred choice for most Public Key Infrastructure (PKI) applications due to its balance of speed and size.

Understanding ML-DSA Variants (FIPS 204)

ML-DSA offers three security levels, each designed to match or exceed the security of existing classical algorithms:

• ML-DSA-44: Level 2 security (comparable to SHA2-256 collision resistance).

• ML-DSA-65: Level 3 security (equivalent to AES-192).

• ML-DSA-87: Level 5 security (equivalent to AES-256).

Pure vs. Pre-Hashed Variants

FIPS 204 defines two signing modes: Pure ML-DSA and HashML-DSA (pre-hashed). In the pure mode, the algorithm itself handles the message digest internally using SHAKE-256. The pre-hashed variant allows a separate hash (like SHA-512) to be computed before signing, which can be useful for extremely large files or resource-constrained environments.

However, the IETF standards governing PKI—specifically RFC 9881 (for X.509 certificates) and RFC 9882 (for CMS)—explicitly disallow the pre-hashed variants. This restriction ensures maximum interoperability across systems and avoids "algorithm substitution" vulnerabilities.

Performance: ML-DSA vs. RSA 2048

The transition to ML-DSA involves a significant shift in resource requirements. While ML-DSA is computationally faster than RSA 2048, it produces much larger keys and signatures.

Metric	RSA 2048	ML-DSA-65	Impact
Public Key Size	~256 bytes	1,952 bytes	~7.6x increase
Signature Size	256 bytes	3,309 bytes	~13x increase
Signing Time	2–5 ms	100–200 µs	~10x faster
Verification Time	Very Fast	Fast	Comparable in practice

While the speed of ML-DSA is a major win for high-volume signing operations, the larger signature and key sizes may challenge legacy protocols that assume small Maximum Transmission Units (MTUs).

Permitted Hashes and the "Balanced" Approach

ML-DSA primarily utilizes the SHAKE-256 extendable-output function (XOF) for its internal hashing operations. For the broader PKI community, ML-DSA-65 with no pre-hashing is emerging as the industry standard. It provides a high security margin (Level 3) while keeping key and signature sizes within manageable limits for modern network protocols.

Current Support and Ecosystem Readiness

Support for ML‑DSA is accelerating across major platforms:

• Azure – Microsoft has publicly committed to PQC adoption aligned with NIST standards; ML‑DSA support is emerging across cloud crypto services.

• Google Cloud KMS – Google is rolling out PQC‑ready APIs and has already deployed ML‑KEM; ML‑DSA support is in active integration phases.

• Microsoft platforms – Windows, .NET, and CNG are incorporating PQC primitives as part of the CNSA 2.0 roadmap.

• HSMs and PKCS#11 – Vendors are adding ML‑DSA support due to its implementation simplicity (no floating‑point arithmetic, predictable performance), making it suitable for hardware acceleration. However, the PKCS#11 version 3.2 (April 2026) is not yet approved.

• Certdog - Implements ML-DSA for software key stores as of version 1.17 - CAs can be created using ML-DSA now. Support for other key stores (e.g. Azure KeyVault and PKCS#11) will be available as soon as supported by the vendor.

In summary: ML‑DSA is now the signature algorithm for the post‑quantum era, and for PKI the practical, standards‑aligned choice is ML‑DSA‑65 (pure). As cloud providers, HSM vendors, and platform stacks continue to adopt FIPS 204, organisations can begin migrating certificate authorities, OCSP responders, and signing services with confidence.