Crypto-Agility: Design for Change
Cryptographic algorithms don't last forever. MD5 fell. SHA-1 fell. RSA will eventually fall to quantum computers. The organizations that migrate smoothly are those that designed for change from the start. This design principle is called crypto-agility — and it's the most important architectural decision you can make for long-lived systems.
What is Crypto-Agility?
Crypto-agility is the ability of a system to switch cryptographic algorithms, key sizes, or implementations without requiring a redesign or full rewrite.
A crypto-agile system treats the cryptographic algorithm as a parameter — something that can be changed by configuration or a software update — not as something hardcoded into the system's fundamental architecture.
Why Crypto-Agility is Especially Critical Now
The post-quantum transition is the largest cryptographic migration in history. We're replacing the foundational algorithms of the internet:
- RSA and ECC key exchange → ML-KEM
- ECDSA and RSA signatures → ML-DSA / SLH-DSA
- Classical Diffie-Hellman → hybrid ECDH + ML-KEM
Systems that hardcoded RSA or ECC will require architectural changes. Systems built with crypto-agility will migrate with configuration changes and library updates.
Crypto-Agility Principles
Abstract Cryptographic Operations
Never call cryptographic primitives directly from business logic. Wrap them in interfaces or classes. Instead of calling RSA.sign(message, key), call Signer.sign(message) where the underlying algorithm is injected. Changing algorithms means changing the injected implementation, not the business logic.
Algorithm Negotiation
Build protocols that negotiate algorithms dynamically. TLS does this — client and server exchange a list of supported cipher suites and pick the strongest mutually supported one. This allows gradual migration: add the new algorithm to the list; let it become preferred; remove the old one later.
Algorithm Identifiers in Data
Tag all encrypted or signed data with which algorithm was used. A JWT or encrypted file should declare "this is AES-256-GCM" or "this is ML-DSA-65" — so future systems know how to process it even after algorithms change.
Cryptographic Inventory
Document every place your system uses cryptography: which libraries, which algorithms, which key sizes, for what purpose. You can't migrate what you can't find. Tools like CBOM (Cryptography Bill of Materials) and static analysis can help automate this.
Use Established Libraries, Not Custom Code
When an algorithm needs to be replaced, switching libraries is far easier than rewriting custom cryptographic code. Use OpenSSL, libsodium, or BoringSSL — maintained libraries that follow standards and get updated when algorithms change.
Hybrid Cryptography: Agility in Practice
A key strategy during the transition to post-quantum is hybrid cryptography — running both classical and post-quantum algorithms simultaneously. The security of the combined scheme is at least as strong as the stronger of the two components.
Hybrid Key Exchange Example: X25519 + ML-KEM-768
Google's deployment in Chrome (and many TLS servers) combines:
- X25519 (classic ECDH) — provides security today against classical computers
- ML-KEM-768 — provides quantum-resistance against future quantum computers
- The two shared secrets are combined (KDF over both) to produce the final session key
An attacker would need to break both X25519 (classical attack) AND ML-KEM-768 (quantum attack) to compromise the connection. This hybrid approach allows migration while maintaining backward compatibility.
Frequently Asked Questions
How do I start building crypto-agility into an existing system?
Start with the inventory: find all cryptographic operations using static analysis or documentation. Then introduce abstraction layers — wrap direct algorithm calls in interfaces. Prioritize high-exposure surfaces first: TLS configuration, API authentication, data-at-rest encryption, code signing. The goal is a "cryptographic services" layer that owns all algorithm decisions, with the rest of the codebase depending only on that layer.
Is crypto-agility about having multiple algorithms or being able to change them?
It's about being able to change them — quickly, safely, and without system-wide impact. Supporting multiple algorithms simultaneously (hybrid schemes) is one implementation of crypto-agility during a transition, but the core concept is architectural: don't hardcode. The goal is a short "algorithm replacement time" — measured in weeks, not years.
Do commercial cloud providers support crypto-agility?
Increasingly yes. AWS KMS, Azure Key Vault, and Google Cloud KMS are adding PQC algorithm support. They're also designed with agility in mind — you configure which algorithm to use, not the underlying code. If you're using cloud-managed cryptography, migrating may be as simple as changing a key policy configuration once your provider supports the new algorithms.
Frequently Asked Questions
What will I learn here?
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.