It’s the job of researchers at the U.S. National Institute of Standards and Technology (NIST) to set the standard for post-quantum cryptography (PQC). Candidate algorithms go through a stringent review by mathematicians like Dustin Moody, as well as other internal and external experts, before they can be standardized for all applicable industries.
Moody works with NIST’s Cryptographic Research Group. For the past decade, he’s led their post quantum cryptography standardization effort. He recently co-wrote Considerations for Achieving Crypto Agility: Strategies and Practices, a whitepaper defining crypto agility and outlining trade-offs and approaches to achieving it.
In this Q&A, Moody discusses what crypto agility looks like, why your data is already at risk, and what companies should be doing now for PQC migration.
At its core, crypto agility is the ability to easily switch to new cryptographic algorithms different from the ones you're using. It also could involve things like turning off old algorithms that you no longer want to use.
The idea is that you're able to easily switch between algorithms, so you can make sure that you're always using the appropriate one that you want to.
That's an important thing to consider, and there's no simple answer. Anytime that you're introducing a new algorithm or putting it into a protocol or application, you have to look at all the different security aspects and analyze them and see if you're comfortable with the security they achieve versus the risks of introducing complexity.
An example of that is if you're going to be combining two algorithms in what's called a hybrid mode. Theoretically, it makes sense that if you do it properly, the only way you can break the hybrid mode is if you break both algorithms. But if it's done wrong, it can lead to downgrade attacks, where breaking the simpler algorithm gets you access to the whole thing.
So there's no clear-cut answer, other than you just have to do a careful analysis. Having time for experts to take a look at it and give it scrutiny helps with that. The number one thing that we want to do is just have a lot of time to evaluate it ourselves internally, as well as experts externally, people in the cryptographic community.
For the algorithms that we ended up selecting, for example, they were first submitted to us in 2016. Some of them had been in academic papers well before then, but they then underwent six years of review before we selected anything for standardization. That gave us enough time to look carefully at the hard mathematical problems that each one was based on and that we could feel comfortable with. It was providing protection against both classical computers as well as quantum attacks from future quantum computers.
So time is the main consideration and then having experts evaluate the algorithm and ensure that there are no known attacks, or it doesn't appear that there are any on the horizon that are making any progress at all.
It's very important. Cryptographers have recognized for a long time that attacks happen where something we thought was secure gets taken down or broken. Or new technology advances to make something obsolete, like what we're seeing with quantum computers that will break the existing RSA cryptosystem and elliptic curve and so forth.
So as we did our process to select new algorithms, cryptographic diversity was one of the key considerations. In the initial submissions, there were three or four main different kinds of mathematical families where these security problems were found, some based on lattices, some based on codes, some based on isogenies or multivariate algebra. And throughout each round of the process, we ensured that we kept that diversity and chose the best algorithms from each of those different families.
Ultimately, we knew we didn't want just one algorithm for that reason, so we selected more than one. So HQC will be the second KEM. For digital signatures, we selected three, and we’re looking for potentially another one or two that we could augment with.
We do want to keep the numbers small for interoperability, because companies don't want to implement several different cryptosystems when there's no need. But we do need to have more than one algorithm available just to protect against any future attack.
We definitely know that it will take a long time to migrate, and that's part of why we started on this so early. We're trying to emphasize this to people that nobody knows when a quantum computer comes out.
Google put out an announcement that they are aiming for a 2029 deadline for PQC migration. But it could take longer to have a cryptographically relevant quantum computer, or maybe somebody comes up with a breakthrough sooner. And so people understand that and that they need to have the new solutions before the computer is there. There is uncertainty as to the date, but it is certain that the transition will take time.
The other piece of this is that you need to migrate a lot sooner than you think. That's best captured by the idea of harvest now, decrypt later: you can imagine your adversary making copies of a huge amount of encrypted data, and just holding onto it until a quantum computer becomes available. And so you're actually at risk now, even if you don't migrate for a while or the quantum computer is not available for 10 to 15 years, because they could have already taken some of your data now and just simply be sitting on it.
We have to try and balance all those things and encourage people to migrate as soon as they can, following a careful plan to ensure that they don't make any mistakes.
PKI and certificates using digital signatures is certainly going to be challenging. We haven't yet come up with the best way to completely do this. When I say we, it's not just NIST, it's all the cryptographers working on this.
One of the challenges for this is because the algorithm we selected, ML-DSA, that most people are going to be using, its signature sizes are a lot larger than what we're used to. So whereas RSA and ECC were a couple hundred bytes, ML-DSA is over 2,000 bytes, so that increased signature size is going to throw a wrench into some of the protocols and applications, particularly when you look at certificate chains and in PKI.
Cryptographers are actively figuring out the best way to tackle this, so that we'll be able to protect our information. The signatures can wait a little bit longer than the key establishment in most cryptographers' eyes because of the harvest now, decrypt later threat. You need to protect that first, and signatures usually can't be exploited until closer to the time of the signature being done.
There are cases where you do need to worry about similar sorts of attacks, but that's why cryptographers attack the one problem a little bit sooner. And right now we're actively working on how to do this. There are some different ideas, like using Merkle trees to organize certificate chains and compress the amount of bytes needed for one of these chains. That idea seems to be gaining some traction, but there is by no means a consensus that everybody's going to do that yet. So it's a very much active area that people are working on to figure out how we're going to use these PQC signatures with our certificates in PKI in a sensible way.
Well, you can't just flip a switch and suddenly be crypto agile. A big part of it is looking at your applications and making sure you aren't hardcoding specific algorithms everywhere. You want to abstract that stuff out so that when you need to swap out a cipher or update a protocol, you can do it without having to rewrite half your codebase. Automating your certificate management is huge too, because doing all of that by hand when standards start shifting is just going to bog everything down.
You also need to make sure your protocols explicitly support algorithm negotiation, so you're not stuck if a specific cipher suite becomes obsolete. For legacy gear or hardware security modules where updating code isn't realistic, using proxies or wrappers gives you a practical path forward without replacing hardware right away. Testing out hybrid modes is another great way to verify your PKI can handle multiple ciphers at once.
It really comes down to building your systems modularly from the ground up so you're not locked into any single algorithm when things change. If you want to dive deeper into this, NIST actually published a report specifically on crypto agility (CSWP 39) which is a great resource to check out.
The federal government is taking steps showing that the PQC threat is real and that we do need to take actions. They've announced timelines for agencies to transition. The overall target date is 2035, although for certain areas like high value assets and high impact systems we have an earlier deadline of around 2030. We want organizations and industries to try and follow the same timelines. You can't wait and just put this off. It's going to be a very complex transition, and so organizations should be getting the education that they need about PQC, and they should be developing a roadmap and building a team with a plan to get to work on that transition.
One of the first steps is to do a cryptographic inventory to find where you're using crypto and what information is being protected by that crypto, so you'll know where you're going to need to start replacing things. Talk to your vendors for the products that you use and see if they've got their roadmaps and transition plans and when they will be PQC ready.
There's a lot of work that needs to be done, and you really don't want to wait to get started on it.
This Q&A is condensed and lightly edited from a phone interview with Dustin Moody. Moody’s views are his own and do not represent the position of SecureW2.
SecureW2 is a leader in modern cloud PKI and certificate-based agentic AI security. Through its Signal blog, SecureW2 works with real human technology journalists to interview a range of top industry subject matter experts and thought leaders.
