Certificates & Proofs / Cert Capacity Calculator
What you will do: Model storage, bandwidth, and CPU impact of migrating your PKI to ML-DSA — adjust cert counts and renewal cadence.
Worked example: Choose the supplied example inputs, run the Cert Capacity Calculator workflow, and inspect the resulting RSA-2048, ECDSA P-256, ML-DSA-44, ML-DSA-65, ML-DSA-87 operations before changing one input and comparing the output.
Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.
For your role
- Executive / Business Leader
- Three inputs, one summary: how much CA storage and handshake bandwidth grow when certificates move from ECDSA to ML-DSA, with the staged hybrid path shown as the alternative.
- GRC / Risk & Compliance
- The Business Impact Summary and the Export CSV give a sourced figure for the certificate side of the migration, with the model's benchmark caveat stated on the page.
- Security Architect
- Enter your certificate count, renewal cadence and TLS handshakes per second and switch between Absolute and Relative to ECDSA: the Business Impact Summary states the archive storage and handshake bandwidth growth for the staged hybrid PKI.
- IT Ops / DevOps
- Fill in the three parameters from your inventory and Export CSV: the figures are the storage and bandwidth the CA and the edge need for the renewal cadence you run.
Educational model — values are based on reference benchmarks and may differ from your production environment. Always benchmark with your actual hardware and workload.
Parameters
Business Impact Summary
Transitioning from ECDSA P-256 to ML-DSA-44 (PQC equivalent security) will increase your CA archive storage by roughly 6.5x and TLS handshake bandwidth by 9.2x. Per-signature CPU cost is broadly comparable between the two on modern AVX2 hardware and is highly implementation- and platform-dependent (ML-DSA signing is SHAKE/AVX2-bound; ECDSA is modular-arithmetic-bound), so published sign-latency numbers vary by 2–3× across sources and CPUs. The robust, reproducible migration cost here is size and bandwidth, not CPU — treat the CPU chart below as one reference point, not a guarantee.
Staged migration: hybrid PKI (classical CA, PQC leaf)
A full flag-day switch to an all-PQC chain is rarely the first step. The realistic near-term path keeps roots and intermediates on ECDSA/RSA (small, long-lived, verified rarely) and moves only the end-entity key to PQC — which confines most of the size increase to a single leaf. Worked example, ECDSA P-256 → ML-DSA-44:
- All-classical leaf = 648 B (baseline)
- Hybrid leaf (ECDSA CA sig + ML-DSA-44 key) = 1,896 B (+193%)
- All-PQC leaf (ML-DSA-44 CA sig + key) = 4,244 B (+555%)
The hybrid leaf avoids the large PQC CA signature, so a staged rollout absorbs a fraction of the all-PQC bloat while still making the end-entity key quantum-safe.
CA Archive (MB/yr)
How this is calculated
certSize = pubKeyBytes + sigBytes + 512
The cert stores the subject's public key, the CA's signature over the cert, and ≈512 bytes of ASN.1 overhead (DN fields, extensions, headers).
archiveMB = certCount × certSize × renewalsPerYear ÷ 1024²
Models the CA database growing by one record per issued cert. If you keep all issued certs (audit trail), this is how much storage you add per year.
Sliders that affect this chart: Certificate count, Renewal cadence.
Size sources: NIST FIPS 204 Table 2 (ML-DSA), RFC 5480 (ECDSA), RFC 8017 (RSA).
Bandwidth (MB/s)
How this is calculated
A TLS 1.3 handshake sends two crypto-heavy messages:
Certificate = pubKeyBytes + CA sigBytes + 512 (ASN.1)
CertificateVerify = sigBytes (server proves ownership of private key by signing the handshake transcript)
payloadKB = (Certificate + CertificateVerify) ÷ 1024
aggregateMB/s = payloadKB × handshakesPerSec ÷ 1024
Assumes the CA and the server leaf cert use the same algorithm family (e.g., ML-DSA CA issuing ML-DSA leaf certs). Hybrid PKI (ECDSA CA + ML-DSA leaf) would reduce the CA sig size in the Certificate message.
Slider that affects this chart: TLS handshakes / sec.
CPU (% of 1 core)
How this is calculated
Models server-side signing cost only (the server signs the CertificateVerify message on every handshake).
maxOps/s = 1,000,000 ÷ signCpuMicros
CPU% = (handshakesPerSec ÷ maxOps/s) × 100
AVX2-optimised benchmarks, single-core 3 GHz x86-64 (Haswell-class). ML-DSA numbers are from the CRYSTALS-Dilithium AVX2 submission (NIST PQC Round 3, Appendix B); RSA and ECDSA from OpenSSL 3.x with CRT and AVX2 scalar-multiplication. Note: RSA signing improves further (~3–4×) with AVX-512 IFMA52 (Ice Lake+), which is not modelled here. Multi-core scaling is linear — divide CPU% by your core count for fleet capacity.
Slider that affects this chart: TLS handshakes / sec.
| Algorithm | CA Archive MB/yr | TLS payload KB | Bandwidth MB/s | Sign ops/sec | CPU % / core |
|---|---|---|---|---|---|
| RSA-2048 | 3,906.3 | 1.3 | 1.22 | 2,500 | 40 |
| ECDSA P-256 | 2,471.9 | 0.7 | 0.69 | 25,000 | 4 |
| ML-DSA-44 | 16,189.6 | 6.5 | 6.36 | 34,483 | 2.9 |
| ML-DSA-65 | 22,022.2 | 8.9 | 8.66 | 22,727 | 4.4 |
| ML-DSA-87 | 29,491.4 | 12.1 | 11.79 | 15,152 | 6.6 |
Try it
Set Relative to ECDSA and raise the renewal cadence. Which figure grows?
Next step
Turn it into a plan: Infrastructure Modernization PlannerThis tool practises the PKI module, phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase.
Related content
Next in Certificates & Proofs