The discussion surrounding quantum computing posing a risk to encryption typically focuses on algorithms. Which encryption standards will break? What new ones will take their place? But that framing misses the crucial point: algorithms never act in a vacuum. It is important to note that every algorithm is built on cryptographic keys, and the method used to generate, store, distribute, and ultimately retire these keys is just as paramount to security as the choice of an algorithm.
Shor’s algorithm, when executed on quantum computers, would not directly attack the AES cipher. It targets the key exchange mechanism that establishes the shared AES key. Which is the crux: more than just replacing your algorithm can save you from being quantum-compromised. It calls for a re-imagining of the key management practices throughout the entire lifecycle.
How Keys are Leaked by a Quantum-enabled Attack
Quantum computing threatens cryptographic keys in two ways, and security teams need to understand each approach independently.
The first is the harvest-now, decrypt-later attack model. Today, an attacker captures encrypted traffic and stores the (ciphertext) along with enough key exchange data to run down the session key once a quantum computer is built to run it. There is no need to reveal the key in real time. It need only to have been sent some time in the past over a quantum-vulnerability key exchange protocol.
The second mechanism applies only to keys with a long lifetime. For years, certificates, signing keys for code or firmware (aka public key infrastructure root keys) have been valid. Another Cloudflare Internet Security Report. A decade-long root CA key created using RSA could be hacked by a quantum computer in an eclipse attack far before it needed to be replaced and was never intended for quick rotation, making it precisely the target of persistent exposure.
It is crucial, as the first step in prioritizing protection work, to have a clear understanding of how each key type is exposed.
See also: Transform Your Life with Daily Discipline and Self-Improvement Tools
An Ideal Key Management Regime in the Face of Quantum Threat
Key management deals with the full lifecycle of a cryptographic key, from its generation and distribution to authorized parties, its use during cryptographic operations, its storage when not in active use, its retirement, and its destruction.
The big-picture threat landscape that informs these key management choices is explored in a detailed overview of quantum computing security for cryptographic keys, explaining how algorithms attack different layers of the cryptographic stack.
The NIST key manifest project provides the fundamental guidance for nearly all enterprise key management systems built upon it. This guidance encompasses generation, creation, storage, handling, and destruction in different critical categories and use cases. With NIST’s standardization of post-quantum cryptography, the key management guidance is being updated to cover the much different size and operational characteristics of post-quantum algorithms, and finally their lifecycle and compare it with what they are replacing for RSA and elliptic curve systems.
The Generation Problem
An immediate and often-overlooked challenge for key generation in a post-quantum world is that post-quantum keys are significantly larger than the keys they replace. The larger sizes of RLWE public keys compared to comparable RSA public keys (hundreds of bytes) and various RLWE signatures in their respective ML-KEM and ML-DSA variants vs. ECDSA signatures.
This size difference influences protocols designed with certain key sizes in mind, hardware security modules (HSMs), where memory for key material is fixed, and certificate constraints when a specific size is required for the associated certificates. The underlying randomness source needs to be sufficient for key generation processes. Regardless of their theoretical strength, post-quantum algorithms remain dependent upon high-quality random number generation to achieve the desired security. If your source of entropy is weak, it compromises the algorithm.
Hardware Security Modules in a Postquantum World
HSMs, or hardware security modules, are the tamper-resistant devices that form the backbone of key management in high-security environments. They keep private keys in a secure memory, and do cryptographic operations inside the device it is never exposed to plaintext to surrounding systems, and supply a root of trust for certificate hierarchies, signing and key wrapping.
A unique challenge for HSM deployments is the quantum transition. Many HSMs in production today were built with firmware written before post-quantum algorithms were standardized and cannot be updated without either a firmware update or a physical replacement. Older devices that are unable to be updated at all will need replacing, but HSM replacement cycles in critical infrastructure environments tend to last a ten year plus.
Recent industry analysis has been direct about this constraint. Federal hardware security reporting has highlighted how the tamper resistance and key isolation properties of HSMs remain essential in a post-quantum world, with the critical need being that next-generation devices support new algorithms through crypto-agile architectures rather than hard-coded algorithm support that cannot be updated.
Key Wrapping: The Chain of Dependency
Key wrapping (or key transport) is the process by which keys are securely wrapped and unwrapped using a different symmetric key.
Key Wrapping: Encrypt one key with another key, usually for storage and transfer. Most enterprise key management systems have a hierarchy of keys where higher level ones protect lower level ones and the root key at the top of that tree is stored in an HSM.
This hierarchy creates a chain of dependencies that must be resolved at each layer during the quantum transition. If the wrapping key at the top of the hierarchy is still vulnerable to quantum attack, then every key it protects is transitively vulnerable no matter how many upgrades have occurred on data-encryption keys further down in the chain to use quantum-resistant algorithms.
All the key wrapping functionality, which is relying on RSA or elliptic curves today needs to be replaced by post-quantum (PQ) based key encapsulation mechanisms. Usually this means requiring coordination of changes across the entire key hierarchy and not working to update systems independently.
Prioritizing Keys for Quantum Protection
The migration of each key in the enterprise environment does not have to be under the same timeline. You can analyze priority the same way you would to other quantum security decisions: urgency is based on data lifetime and key lifetime.
Not as urgent are keys that form sessions for data with very short useful lifetimes: anything that decides a few pieces of data is less important than the long-lived keys-to-trust-hierarchies. Although there are many other nontrivial secrets linked to our global IT, root CA keys, code-signing keys used to authenticate firmware that will run for decades, and master keys in HSMs that wrap everything else below them are natural targets for a key-centric quantum migration.
Getting to a Quantum-Ready PKI
Adopting a quantum-ready key infrastructure involves changing procedures for generating keys, auditing and potentially replacing HSM hardware, refining key wrapping chains to use post-quantum encapsulation methods, and ensuring on time that the new algorithm characteristics are sufficiently satisfied by both existing as well as future sizes (as affine linear dependence over finite fields) when it comes to storage and distribution mechanisms.
It’s a large investment, but this is where quantum security really starts to take shape. All of the other pieces of the transition rely, ultimately, on backing up cryptographic keys in a way that survives the full quantum threat model.
Frequently Asked Questions
What role does key rotation play in solving the quantum threat?
Key rotation shortens the time span during which any individual key is potentially exposed to harvest-now, decrypt-later attacks. Reducing the effective lifetime of various key validity periods for long-lived keys is a pragmatic risk remediation that can often immediately be put into practice as migration work continues, even before the actual deployment of post-quantum algorithms.
Are there any available ways of upgrading existing HSMs to support post-quantum key operations?
The former is capable, thanks to vendor firmware updates; the latter not so much due to hardware limitations. Because of the potential effect, organizations are encouraged to confirm their HSM vendor’s post-quantum roadmap and build replacement cycles – for devices that have no practical update path – into their plan to migrate.
If you migrate to post-quantum algorithms, do we need to change the way key are persisted?
Not needlessly, with the exception of physical storage location but key sizes will increase, so it may necessitate an upgrade to your storage expansions, database schemas and anything that has fixed size fields storing key material. Key management platforms must be evaluated to support the larger key and signature sizes of post-quantum algorithms.
