Crypto-Agility

Crypto-agility is the engineering property that lets you change cryptographic algorithms without re-architecting the system. It is the foundation of every PQC migration: if swapping an algorithm is cheap, the next swap — to PQC, to a fixed PQC parameter set, or away from a broken scheme — is just a configuration change.

What it means

An agile system treats the choice of algorithm as data, not as a structural assumption baked into the code. You can deploy a new KEM or signature scheme, negotiate it with peers, and retire the old one — all without touching application logic, redefining message formats, or rebuilding hardware.

PQC makes agility non-negotiable for two reasons. First, key, ciphertext, and signature sizes are much larger and differ between schemes, so any code that assumes a fixed size will break. Second, the PQC standards are young; you should expect to re-tune parameters and possibly swap primitives again as confidence and guidance evolve.

Design principles

• Algorithm negotiation. Endpoints advertise supported algorithms and agree at runtime — never hard-wire a single scheme. Negotiation must be integrity-protected and enforce a minimum security floor; otherwise agility can become an entry point for downgrade attacks.
• Cryptographic abstraction layer. Application code calls encrypt(), sign(), establish_key() — not rsa_encrypt(). The concrete algorithm lives behind the interface.
• No hard-coded sizes. Never assume a 256-bit key, a 32-byte signature, or a fixed buffer. Size everything dynamically from the chosen algorithm's parameters.
• Versioned protocols and formats. Messages, tokens, and certificates carry an algorithm identifier and a version so old and new can coexist during transition.
• Central crypto policy. Allowed algorithms, key lengths, and deprecation dates live in one governed place, not scattered across services.
• Identify the crypto provider. Route through a single library or service so you can audit and upgrade in one place.

Anti-patterns: avoid crypto-spaghetti

"Crypto-spaghetti" is what you get when cryptographic decisions are scattered and frozen across a codebase. Watch for:

• Hard-coded algorithm names and OIDs in dozens of files.
• Fixed-length buffers and struct fields that overflow or silently truncate larger PQC keys.
• Serialization formats with no algorithm or version field.
• Home-grown crypto inlined into business logic.
• Key sizes assumed by both ends of a protocol with no negotiation.

Retrofitting existing systems

Most organizations cannot rebuild from scratch. A pragmatic retrofit path:

1. Inventory call sites. Use the cryptographic discovery process to find every place crypto is invoked.
2. Introduce a façade. Wrap the existing library behind a thin abstraction that initially just forwards calls.
3. Externalize parameters. Move algorithm names, key sizes, and curve choices out of code into configuration or policy.
4. Add negotiation. Extend protocols and formats with algorithm/version identifiers; keep accepting the old identifier during transition.
5. Pilot a swap. Prove the façade by swapping in a hybrid scheme on one path — see Hybrid Cryptography.
6. Generalize and govern. Roll the abstraction across services and put the allow-list under central policy.

# Anti-pattern: algorithm and size baked in
sig = rsa_sign(priv_2048, msg)          # breaks the day you move off RSA
assert len(sig) == 256

# Agile: algorithm chosen by policy, size derived dynamically
signer = crypto.signer(policy.signature_alg)   # e.g. "ml-dsa-65" or "rsa-pss-3072"
sig = signer.sign(msg)
store(sig, alg=signer.alg_id, sig_len=len(sig))  # length comes from the signer

Standards & references

• NCCoE SP 1800-38 — migration practice guide covering discovery and agile architecture.
• ETSI Quantum-Safe Cryptography — standards and guidance for quantum-safe deployment.
• NIST IR 8547 — transition plan that drives the need for agile algorithm swaps.
• Resources — full standards register