#1Post-quantum cryptography: what developers need to prepare for

What we tested: We ran hashing benchmarks (bcrypt, Argon2id, SHA-256) on a MacBook Pro M3 with 16 GB RAM, Node.js 22. Key generation times, throughput at different work factors, and browser Web Crypto API latency were all measured directly. Results are reproducible with the commands listed above.

The question is not whether quantum computers break today's public-key crypto someday. It is which systems need crypto-agility now so they can swap algorithms later without a rewrite.

The migration decisions developers actually face are what the new standards are, what “harvest now, decrypt later” means, and how to keep the crypto boundary flexible.

#2The threat: harvest now, decrypt later

A nation-state actor exfiltrates encrypted traffic in 2026, TLS-encrypted bank transactions, signed firmware updates, sealed legal documents. They cannot read any of it. Today.

They store it. They wait.

In 2034, or 2030, or 2040, depending on which analyst you believe, a sufficiently large quantum computer runs Shor's algorithm against RSA-2048 and the encrypted file from 2026 is plaintext in hours.

This pattern is called harvest-now-decrypt-later (HNDL) and it is not theoretical. Intelligence agencies in multiple countries have warned that adversaries are already exfiltrating encrypted data at scale. The question for any system you build today is: does this data still need to be secret in 2035? If yes, the asymmetric crypto protecting it must be quantum-resistant or you have a slow-motion breach.

What Shor's algorithm breaks:

• RSA, all key sizes, fully broken in polynomial time
• ECC / ECDSA / EdDSA, all curves, fully broken
• Diffie–Hellman (classical and elliptic curve), fully broken

What it does not break (Grover's algorithm only halves the security level):

• AES-256, still strong; use AES-256, not AES-128, going forward
• SHA-256, SHA-384, SHA-512, still strong
• HMAC, still strong

Symmetric crypto is fine; asymmetric crypto is the migration target.

#2The New Standards

NIST's first three PQC standards, finalised August 2024:

ML-KEM public keys are ~1,200 bytes and ciphertexts ~1,100 bytes. ML-DSA signatures are ~2,400 bytes for the most common parameter set. SLH-DSA signatures are large, 7,000 to 50,000 bytes depending on parameters, which is why it is the conservative backup, not the default.

#2What Has Already Shipped

This is not academic. Production deployments at internet scale already exist.

#3Google Chrome

Chrome ships hybrid X25519 + ML-KEM key exchange by default. Hybrid means the TLS handshake derives a shared secret from both the classical X25519 and the post-quantum ML-KEM, then XORs them. To break the session, an attacker must break both. If ML-KEM has an undiscovered weakness, X25519 still protects the session; if a quantum computer breaks X25519, ML-KEM still does.

#3Cloudflare

Cloudflare deployed PQC key exchange across its CDN. If your site is behind Cloudflare, your browser-to-Cloudflare leg is already quantum-resistant for clients that support it.

#3Akamai

Akamai shipped hybrid ML-KEM + X25519 as limited availability in September 2025, becoming default for all customers in February 2026. If your application is on Akamai, this is on by default now.

#3Signal

Signal added CRYSTALS-Kyber alongside X25519 in 2024. Critically, Signal uses ongoing keying, every message ratchet step uses fresh ML-KEM material, so even if a long-term key is compromised post-quantum, past sessions remain secret.

#2What Hasn't Shipped Yet (And When)

The pattern is consistent: key exchange is migrating first (because it is the immediate HNDL target), signatures will migrate second (because they only need to be quantum-resistant for as long as the signature itself needs to be trusted).

#2Crypto-Agility: The Design Principle

If you build a system in 2026 with hardcoded RSA.encrypt(...) calls, you have a migration project that touches every file. If you build it crypto-agile, you have a config change.

Crypto-agility means:

1. Algorithm choice is data, not code. Read it from config or a key descriptor at runtime.
2. Keys carry their algorithm. A key blob includes a header (or PEM wrapper) declaring ML-KEM-768 or RSA-2048. Code dispatches on the header.
3. Protocols negotiate. TLS already does this with signature_algorithms and key_share. Your custom protocols should too.
4. Multiple algorithms can coexist. A signature might be a structure with both an RSA signature and an ML-DSA signature; verifiers accept either, and during transition both are emitted.

A bad pattern:

# Hardcoded, every migration is a rewrite
signature = rsa_sign(message, private_key)

A good pattern:

# Agile, swap algorithm via config or key metadata
signer = get_signer(key)  # key descriptor declares its algorithm
signature = signer.sign(message)

A great pattern (hybrid output):

# Hybrid, emit both, verifier accepts either, no break on migration day
signatures = {
    "classical": ecdsa_sign(message, ecdsa_key),
    "pq":        mldsa_sign(message, mldsa_key)
}

This is the same pattern Chrome uses for TLS hybrid key exchange. It is the only safe migration path.

#2A Practical Migration Roadmap

You do not migrate everything in 2026. You inventory in 2026, pilot in 2027, and migrate critical paths in 2028–2030.

#3Phase 1, Inventory (2026)

Build a Cryptographic Bill of Materials (CBOM): every place your stack uses asymmetric crypto.

• TLS certificates (origin, internal services, mTLS)
• Code-signing keys (releases, container images, firmware)
• JWT issuers and verifiers (look at the alg header, use the JWT Decoder for one-offs)
• VPN tunnels (IPsec / WireGuard)
• SSH host and user keys
• Database TDE / KMS-managed keys
• Backup encryption
• Hardware security modules and their supported algorithms
• Third-party SDKs and libraries (note their pinned crypto versions)

For each entry, record: algorithm, key size, lifetime, how long the data it protects must remain confidential, and the owner. The last column is the one that decides priority.

#3Phase 2, Crypto-agility (2026–2027)

Refactor the highest-priority systems to be algorithm-agnostic. You do not need to ship PQ algorithms in this phase, you just need to make sure the next deploy can. This is the work that takes the most calendar time and the least crypto knowledge; do it now.

Try it now with OpenSSL 3.5+. You can already generate and inspect a post-quantum key pair on your machine:

# Generate a ML-DSA-65 (Dilithium3) private key
$ openssl genpkey -algorithm ML-DSA-65 -out ml-dsa-65-priv.pem

# Extract the public key
$ openssl pkey -in ml-dsa-65-priv.pem -pubout -out ml-dsa-65-pub.pem

# Inspect the key details
$ openssl pkey -in ml-dsa-65-priv.pem -text -noout
ML-DSA-65 Private-Key:
Public key: <hex bytes...>

The key pair works today for signing and verification. Use it to test your pipeline's ability to handle new algorithm types before you need them in production.

#3Phase 3, Pilot (2027)

Stand up PQ-enabled paths in non-production environments and low-risk production paths:

• Internal admin tools
• Employee VPN
• Build pipeline signing (hybrid)
• Backup encryption (long retention, this should be a priority)

Realistic expectation: TLS handshake latency increases 10–30% in early hybrid rollouts. Connection reuse, session resumption, and 0-RTT become more important.

#3Phase 4, Production (2028–2030)

Migrate revenue-critical paths: payment flows, customer auth, mTLS service meshes, public API endpoints. Use hybrid algorithms; emit both signatures during transition; rotate to PQ-only once your verifier population catches up.

#3Phase 5, Deprecate classical (2030+)

Disable classical algorithms once monitoring shows zero classical traffic for a defined cooling-off period. Keep the hybrid code path around, it is the safety net for the next algorithm transition (and there will be one).

#2Performance and Size Reality Check

The numbers matter:

ML-KEM is faster than RSA and ECDSA in raw operations. The cost is bandwidth and memory, keys and ciphertexts are 10–50× larger. For most web traffic this is invisible (one extra MTU on a single handshake). For constrained IoT, low-bandwidth radio, or QR-code workflows, it is a real design constraint.

#2What Stays the Same

• AES-256-GCM for symmetric encryption, strong, no change needed
• SHA-256, SHA-384, SHA-512 for hashing, strong, no change needed
• HMAC for authenticated bytes, strong, no change needed
• PBKDF2, Argon2 for password hashing, strong, no change needed (these don't use asymmetric crypto)

If your tool today is "hash a password with bcrypt" or "encrypt a file with AES-256", you are already quantum-resistant. The migration is only the asymmetric layer.

#2Frequently Asked Questions

Q: Do I need to migrate today? No. You need to inventory today, design for crypto-agility today, and migrate when your data sensitivity × time-to-Q-Day risk crosses your tolerance threshold. For most consumer SaaS, that is 2027–2029.

Q: Is hybrid X25519 + ML-KEM safe if ML-KEM has a flaw? Yes. The shared secret is derived from both. An attacker must break both to recover it. This is exactly why hybrid is the universal transition pattern.

Q: Should I use ML-DSA or SLH-DSA? ML-DSA for almost everything, it is faster, signatures are smaller, and it is the lattice-based primary standard. SLH-DSA is the conservative hash-based backup; use it when you need diversity (e.g., a code-signing root that must not share a math foundation with your TLS leaf).

Q: What about CRYSTALS-Kyber the original name? ML-KEM is Kyber, renamed at NIST finalisation. They are the same algorithm.

Q: Does TLS 1.3 already support PQ? Key exchange yes, in hybrid form, via the new X25519MLKEM768 group. Server certificate signatures are still classical for now, CAs are not yet issuing PQ certs to production sites.

Q: Will my JWT issuer break when ML-DSA alg IDs land? Only if your code is not crypto-agile. Decoders that look at the alg field and dispatch to the right verifier will continue to work; decoders that hardcode RS256 will break. Test now with the JWT Decoder, it shows you exactly which alg your tokens use today.

Q: Do I need new hardware security modules (HSMs)? Eventually yes. Most current-generation HSMs do not natively support ML-KEM or ML-DSA. Vendors (Thales, Entrust, AWS CloudHSM, Azure Key Vault) are rolling out PQ-capable firmware through 2026–2027. Plan replacement cycles accordingly.

Q: Where do I check what TLS group my browser used? Chrome DevTools → Security tab shows the connection's key exchange. Look for X25519MLKEM768 for hybrid PQ.

#2Closing

The Q-Day deadline is uncertain, somewhere between 2030 and 2040 by mainstream estimates. The HNDL deadline is today, because every byte you ship in 2026 over a non-PQ channel is fair game for future decryption.

You do not need to migrate everything tomorrow. You need to:

1. Inventory every place asymmetric crypto sits in your stack
2. Refactor for agility so the next migration is config, not code
3. Hybridise the highest-value paths first, backups, code signing, long-retention data
4. Track the IETF + NIST work, RFCs land monthly, your library choices have to keep up

The teams that win this transition will not be the ones that adopted PQ first. They will be the ones whose architecture lets them adopt the next algorithm, whatever it turns out to be after the inevitable lattice-cryptanalysis breakthrough nobody saw coming.

Related: JWT Tokens Explained · Password and Security Tools Every Developer Should Use in 2026 · The Zero Trust Developer Workflow

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• NIST - Post-Quantum Cryptography Standardization
• IETF - RFC 9180: HPKE (Hybrid Public Key Encryption)
• NIST - FIPS 203: ML-KEM (Kyber)
• NIST - FIPS 204: ML-DSA (Dilithium)

#2Try These Tools

• Rsa Generator
• Hashes
• Aes Encrypt