Post-Quantum Cryptography Is Coming: What the Transition Really Costs
In August 2024, NIST published three post-quantum cryptography standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). These are the algorithms that will replace RSA and elliptic curve cryptography once sufficiently powerful quantum computers exist. The standards are final. The transition clock has started.
Most coverage of post-quantum cryptography focuses on the threat — "harvest now, decrypt later" attacks, the timeline to cryptographically-relevant quantum computers, the sectors at greatest risk. Far less attention has been paid to the practical question of what the transition actually costs organisations that need to migrate real systems.
This post is based on research I conducted benchmarking FIPS 204 (ML-DSA-65) and FIPS 205 (SLH-DSA-SHA2-128f) against Ed25519 in a simulated high-volume retail transaction environment. The numbers are concrete and the implications are significant enough that organisations should be thinking about them now.
Why Signatures Are the Hard Part
Key encapsulation — the mechanism that secures session keys in TLS — is relatively straightforward to migrate. ML-KEM (FIPS 203) has already been deployed experimentally by Google and Cloudflare with minimal friction. The story for digital signatures is more complicated.
Signature algorithms are used everywhere: authenticating transactions, signing software updates, verifying API calls, securing device-to-device communication. And the new post-quantum signature algorithms come with a fundamental trade-off: they are much larger and, in some cases, meaningfully slower than what they replace.
The Numbers
Benchmarked on commodity hardware (Intel Core i7, 16GB RAM, Ubuntu 22.04 LTS, using the liboqs reference implementation):
Signature size
- Ed25519: 64 bytes
- ML-DSA-65 (FIPS 204): 3,309 bytes — 52× larger
- SLH-DSA-SHA2-128f (FIPS 205): 17,088 bytes — 267× larger
Signing operations per second
- Ed25519: 283–300 ops/sec
- ML-DSA-65: 177–191 ops/sec (approximately 63% of Ed25519 throughput)
- SLH-DSA-SHA2-128f: 86 ops/sec (approximately 30% of Ed25519 throughput)
To put the bandwidth implications in context: at 4.3 million transactions per day (a mid-size UK retail operation):
- Ed25519: 0.3 GB/day in signature data
- ML-DSA-65: 14.2 GB/day
- SLH-DSA: 73.5 GB/day
Annualised egress cost at current UK cloud pricing:
- Ed25519: approximately £10/year
- ML-DSA-65: approximately £466/year
- SLH-DSA: approximately £2,400/year
The carbon footprint follows the same pattern. Annual CO₂ equivalent for signature traffic at this volume: Ed25519 at 0.76 kgCO₂e, ML-DSA-65 at 1.26 kgCO₂e, SLH-DSA at 2.74 kgCO₂e.
What This Means in Practice
For most organisations, the bandwidth and compute costs of switching to ML-DSA-65 are manageable. A 46× increase in signature size sounds alarming, but at low transaction volumes the absolute numbers are small. The cost and carbon impact only become material at scale — payment processors, high-frequency APIs, IoT fleets signing thousands of messages per second.
SLH-DSA is a different story. It offers stronger security assumptions (hash-based, no reliance on structured lattice problems) but at a bandwidth cost that rules it out for anything high-volume. It belongs in use cases where signing is infrequent but the security requirement is long-lived: document signing, software release signing, certificate issuance.
The performance gap matters too. ML-DSA-65 at 63% of Ed25519 throughput is fine for most applications. If you're currently running Ed25519 with comfortable headroom, you have room to absorb the drop. If you're already near capacity, post-quantum migration becomes a capacity planning exercise as much as a cryptography exercise.
The Practical Recommendation: Crypto-Agility First
For UK organisations planning their post-quantum transition, three things are clear from this research:
1. Start with an inventory. You cannot plan a transition without knowing what you have. Every TLS certificate, every code-signing key, every API authentication mechanism, every device that generates or validates signatures. This inventory work takes time and is best started now, before urgency creates pressure to cut corners.
2. Build for crypto-agility. The most important architectural decision you can make is to decouple your systems from specific algorithm implementations. Applications that hard-code Ed25519 will require code changes when you migrate. Applications that treat the signing algorithm as a configuration parameter can be switched without code changes. This is the difference between a controlled migration and an emergency one.
3. Choose algorithm based on use case, not headline security level. ML-DSA-65 (NIST Security Level 3) is the right starting point for high-volume transaction signing. SLH-DSA belongs in lower-frequency, higher-assurance contexts. Applying SLH-DSA everywhere because it sounds more secure will create bandwidth and compute costs that are difficult to justify and difficult to sustain.
The Timeline Question
The most common pushback on post-quantum migration planning is the timeline. "Cryptographically-relevant quantum computers are still a decade away." This may be true. The problem is that "harvest now, decrypt later" attacks require no quantum hardware today — adversaries can collect encrypted data now and decrypt it once the capability exists. For data with a long confidentiality requirement (healthcare records, legal communications, national security data, long-term contracts), the threat is not future-dated.
NCSC's guidance for UK organisations is to plan for migration, not to wait for urgency. That planning should begin with understanding what you have and what the transition will cost — which is precisely what the benchmarks above are designed to help with.
The question is not whether to migrate. It is how to migrate without disrupting systems that were never designed to be changed.
The organisations that are best placed when the transition becomes mandatory are those that used the available time to understand their exposure, build agility into their architecture, and run their own cost modelling rather than waiting for a standard to tell them what to do.