"The future is already here - it's just not evenly distributed” is an apt description of the impact of quantum computers on cryptography and its use in our identity systems. We all know that quantum computers are predicted to be able to break the cryptographic algorithms used in today’s identity systems (RSA, Elliptic Curve, etc.) at some unknown point in the future. But this possibility has huge implications *right now*. “Disruptive” is an understatement. *Every* piece of software using cryptography has to be updated *before* Cryptographically Relevant Quantum Computers (CRQCs) are created (and we don’t know when that will be). “Store now - decrypt later” attacks require action now, not later. Are you using software and protocols that may never be updated for the post-quantum world (such as SAML)? Are you comfortable with your migration path to fully quantum-safe software? This presentation will help you evaluate what you need to do when and how and why to avoid being a victim of the Post-Quantum Apocalypse.
The Post-Quantum Apocalypse Is Already Upon Us
Quantum computing’s ability to break widely used classical cryptography is an uncertain future event with immediate consequences because adversaries can capture encrypted traffic today and decrypt it later once quantum capabilities arrive. That “store now, decrypt later” threat forces organizations to ask which currently transmitted data would still be damaging if revealed in the future and to move sensitive communications toward quantum-safe protections now rather than waiting. A second near-term driver is long-lived digital signatures—such as code-signing for IoT devices that may never be updated—where validity and trust must persist into a post-quantum era, making early adoption of quantum-safe signatures important.
Two main approaches exist for quantum-safe deployment: pure post-quantum algorithms and hybrid schemes that combine post-quantum and traditional algorithms. Pure approaches reduce overhead and avoid dual-operation size and computational complexity, while hybrid approaches hedge against the possibility that newly standardized post-quantum algorithms could later be weakened, offering safety until both components are broken. Standards and policy are evolving unevenly across jurisdictions and industries; risk assessments and emerging rules imply commercial pressure, including claims that some markets may become inaccessible after 2030 without software updates, regardless of when quantum threats fully materialize.
Practical trade-offs complicate adoption: post-quantum key and signature sizes can be dramatically larger than current options, risking buffer and integration issues, even as performance may be competitive or better in some cases. Standardization is progressing across many protocols and ecosystems (e.g., TLS, X.509, COSE/JOSE-like signing), but working groups differ on whether to standardize pure or hybrid modes and which hybrid combinations to bless, since the combination space can explode. Despite the uneven rollout, deployments are already happening at scale, with a reported 40% of HTTPS requests being post-quantum safe due to major internet vendors enabling it. The core call to action is to inventory cryptography-dependent software, plan upgrades, recognize that some legacy stacks may never be updated, and coordinate deployments so that new algorithms interoperate—while overcoming the hardest challenge: motivating action now amid uncertainty.
- Quantum computers are expected to be able to break classical cryptographic algorithms at some unknown point in the future.
- Adversaries can capture encrypted network traffic today and store it for future decryption once quantum capabilities are available.
- Some digital signatures must remain verifiable for long periods, including signatures on code shipped in IoT devices that may never be updated.
- Quantum-safe deployments can be implemented using either pure post-quantum algorithms or hybrid combinations with traditional algorithms.
- Hybrid schemes remain secure unless and until both the classical and post-quantum components are broken.
- Some jurisdictions and EU use cases require a hybrid approach for post-quantum adoption.
- Post-quantum public keys and signatures can be much larger than traditional equivalents, creating buffer and payload risks in existing software.
- Post-quantum algorithms can outperform some traditional algorithms in speed for certain parameter sets, despite larger sizes.
- National post-quantum standardization efforts are underway in multiple regions, including the United States, Europe, China, South Korea, Japan, and Russia.
- A reported 40% of HTTPS requests were already post-quantum safe as of last year due to enablement by major internet vendors.
- “The Post-Quantum Apocalypse Is Already With Us.”
- “The future's already here. It's just not uniformly distributed.”
- “Every piece of software that uses cryptography that you use is either going to have to be updated or replaced.”
- “They just suck up all the encrypted traffic on TLS and some other channels, and they store it.”
- “What data are you sending over encrypted channels that you really don't want to be decrypted later?”
- “Thwarting this attack requires action now, not later.”
- “If you're using a hybrid, you're safe until both are broken.”
- “The trade-offs are not obvious.”
- “Do you want 15 combinations in your code? Almost certainly not.”
- “The hardest thing of all… is convincing people to act now in the face of uncertainty.”
- Inventory all software, protocols, and devices that rely on cryptography, then map where upgrades or replacements will be required.
- Identify data that must remain confidential long-term and prioritize quantum-safe protection for those channels now.
- Treat long-lived signatures (e.g., code-signing for embedded or unpatched devices) as an immediate migration priority.
- Decide between pure and hybrid deployments based on risk tolerance, regulatory expectations, and engineering constraints.
- Avoid implementing an excessive number of hybrid combinations; select a small, interoperable set aligned with standards and partners.
- Validate buffer sizes, message formats, certificate handling, and storage assumptions to accommodate larger post-quantum artifacts.
- Coordinate migrations with vendors, customers, and relying parties to prevent interoperability failures during rollout.
- Track relevant standards progress across the protocols you use (e.g., TLS, X.509, token signing formats) and time upgrades accordingly.
- Plan for legacy technologies that may not be maintained and develop replacement strategies where post-quantum upgrades are unlikely.
- Build an internal communication plan that addresses uncertainty directly to accelerate decision-making and action.
- Capturing encrypted traffic now creates a present threat even if quantum decryption is years away.
- Long-lived trust artifacts like code signatures force earlier adoption than short-lived tokens and sessions.
- Hybrid cryptography reduces algorithm-break uncertainty but increases complexity, requiring careful standard and implementation choices.
- The toughest work is deployment: upgrading software, coordinating counterparties, and avoiding breakage in real environments.
- Acting under uncertainty is the main barrier, so preparation must start before timelines are “certain.”
Well, thank you, Inge. That is actually very complementary to what I'm going to be doing with you. I'm Mike Jones, and I chose the intentionally provocative title, The Post-Quantum Apocalypse Is Already With Us, and I will explain what the truth of that is.
So, a science fiction writer, William Gibson, wrote, The future's already here. It's just not uniformly distributed. And I think that's very true of the quantum computer situation.
And, as our previous speaker was saying, it's potential impact on our security and identity systems. So, most of you know, and if you were in the previous talk, you know that quantum computers are expected to be able to break the classical cryptographic algorithms we use at some point. We don't know when. This possibility has huge implications, some of them now. As a teaser, if this future comes true, every piece of software that uses cryptography that you use is either going to have to be updated or replaced. Saying that that's disruptive is, shall we say, an understatement.
So, but why do anything now? This is the future, right?
Well, there's this attack, which, among others, nation states have the resources to affect, where they just suck up all the encrypted traffic on TLS and some other channels, and they store it. And they store it until the post-quantum computers come along, or until the quantum computers come along, and they can decrypt it.
So, the question for you now is, what data are you sending over encrypted channels that you really don't want to be decrypted later? If there's any such data, you really want to be thinking about how do you get it to be over encryption channels that are quantum safe? Thwarting this attack requires action now, not later. What's another reason?
Well, there's long-lived digital signatures. Yes, there's a lot of things that are short-lived, like the ID tokens that I have. The ID tokens that I helped invent are generally short-lived, but there are signatures, such as the signatures over code in IoT devices that may not ever get updated, that if you want to know that they're valid after this future post-quantum world comes into play, you're going to have to start using quantum safe signatures now.
So, a little bit of tutorial. Quantum safe algorithms come in two flavors. There's the pure ones, such as the use of MLChem with TLS 1.3. There's hybrid ones, where you combine a post-quantum safe algorithm with a traditional algorithm.
Now, there's arguments for both outcomes, or for both choices. If you use just a pure post-quantum algorithm, it's lower overhead. You're not doing two operations and then combining them, and it avoids both computational and size complexity. On the other hand, the argument for using combined algorithms is you don't actually know whether the pure post-quantum algorithms are going to be broken or not. We didn't know that MD5 was going to be broken. We didn't know that SHA-1 was going to be broken.
There's a lot of other things that have been broken or weakened over the years, and these new algorithms, while different, are not immune to clever cryptographers figuring out how to break them. The interesting thing about the hybrid algorithms is it doesn't matter whether the existing algorithms or the post-quantum algorithms are broken first, or how they're broken. If you're using a hybrid, you're safe until both are broken. There are jurisdictions, including some use cases in the EU, that require use of a hybrid approach. Others are using the pure approach.
It's all over the map, and I'll talk about that. So, caveat. I am not a cryptographer. I'm not going to give opinions on the strength of the algorithms, which ones you should use, and what use cases. I assume that if you want to understand that stuff, you will talk to cryptographers, and you will also talk to engineers about which algorithms are a good fit for your applications. I don't have the crystal ball. I don't know any more than the previous speaker did when or if this will come into play.
However, the EU, NIST, lots of other governments and organizations have done risk assessments, and there's some legislation around this as well, such that if you want to stay commercially relevant, for instance, there's markets you won't even be able to sell to after 2030 if you don't update your software before that. So, whether or not the post-quantum threat comes true by then, commercially you're going to have to get on it.
Now, the trade-offs are not obvious, and again, this is where you're going to have to do your own research. I'll give you some examples.
So, key sizes and signature sizes are very different. ECDSA, public key size 64.
MLDSA 44, about 65 times that. Signatures, a similar spread.
So, you know, you're going to run out of buffers if you had static buffers. However, it turns out that MLDSA 87 is faster than ECDSA with P251 or 521.
So, you know, is size or computation or speed your gating factor? It matters for your applications which you choose.
Now, there are national standards happening around the world. A lot of people are familiar with the NIST standards in the United States and other jurisdictions. Some of them are using them. Some of them are done.
MLDSA, MLCHEM, SLHDSA are done. Others, they're still tweaking at the margins. Others are not done, and there's a second round of standards competition in the United States for additional algorithms. But this is happening around the world. There's European guidance which you can follow this link to. China is running a competition much like NIST did.
But, you know, within a few years, there will be approved algorithms for commerce in China. South Korea is running one. Japan has one. Russia has one. And so it goes. It's a big world. All these algorithms will be, for the most part, public.
So, you know, if you like the Japanese ones, use them if you have implementations. So, I'm a standards professional. What is the state of the standards? In the ITF, for instance, post-quantum is touching so many working groups, it's really hard to keep track of, even though I have a client paying me to do so.
You know, TLS, you would think of. LAMPS, which is X509.
COSE, HOSE, IPSEC, Cryptographic Forum Research Group, et cetera. I will tout that there was a big accomplishment yesterday in the standardization space in that the COSE and HOSE RFC for MLDSA was finished yesterday.
I mean, it was actually stable in July. But that means that there's now a standard for how, for instance, to sign a JSON web token with MLDSA.
So, that's progress. TLS is standardizing both pure and hybrid algorithms. The LAMPS working group, which is the X509 certificates and whatnot, have probably gotten the furthest down the standardization pike.
So, but there's still a lot of work in progress. And in fact, a lot of the discussions in the ITF working groups, and no, there's not one set of decisions. Every working group is making its own decisions. A lot of the discussions are about do you standardize hybrid or pure algorithms? And when there's hybrid ones, gosh, there could be a whole combinatorial set of combinations. For instance, if you took the three standard ECDSA algorithms and the two EDDSA algorithms, and you crossed it just with the three post-quantum MLDSA algorithms, you could have 15 combinations.
Do you want 15 combinations in your code? Almost certainly not. And so then, you know, while there's a consensus to standardize only a few, deciding which combinations get standardized is an active discussion in many cases.
So, as I started, the future's already here. It's just not evenly distributed. Role arts are gated by standards progress. Some deployments are already using existing standards. As far as the future already being here, a cryptographer at Ericsson, John Mattson, reported last year that 40% of HTTPS requests are already post-quantum safe.
Well, how is that possible? It turns out that Google and Cloudflare and a number of other vendors who are very Akamai prominent in the internet space decided they would turn this on now in part because of the store now decrypt later attacks. I'm sure that number has gone up, and that's possible because the SLHTS or the MLChem standards got done. As far as Fido and Yubico, they actually do have authenticators using MLDSA, using those code points that we got adopted in July.
And yes, you're right, it's different hardware. So, in conclusion, I'm going to give you a call for action and how to maybe think about this. One thing to do, again, the hygiene you should already have been doing is inventory your software and make a plan for what you're going to do. I'll jump ahead. There's a lot of software that's never going to get updated.
So, for instance, almost no commercial SAML2 implementations are still maintained. And there's not a plan to even do post-quantum XML desig and XML encryption, as far as I know.
So, you know, people are fond of saying SAML is dead. I'm not trying to kill it, but the writing's kind of on the wall. On the other hand, you know, Chrome is already post-quantum safe.
So, what's hard about this? Developing post-quantum cryptographic algorithms is hard, but that's what cryptographers are doing.
So, great. Creating standards is hard, but that's what I and others do.
So, okay. Updating software to use the standards, to use the algorithms, is hard and it requires your vendors and sometimes you to take responsibility and actually do it. What's harder than that is deploying the updated software into your real environments, both just because updating is hard in general, but you're going to have to make sure that you're not breaking stuff. If you're using new algorithms and the partners you're talking to are not, it's not going to go very well.
So, there's a lot of planning and coordination required to do that. But in my analysis, the hardest thing of all, about all of this, is convincing people to act now in the face of uncertainty.
So, that's why I say that the post-quantum apocalypse is already upon us and it's time to prepare and act. Thank you very much.
