Quantum Threatens Cryptography

When you and I access our bank accounts, or we send information across the internet, or we retrieve our health records from the hospital, the technology that is keeping all of that secure is public key cryptography. It does that behind the scenes. We never really have to think about it. Public key cryptography depends on a mathematical problem that is difficult for a classical computer to solve in a feasible amount of time— we’re talking billions and billions of years. Quantum computers approach that mathematical problem a little bit differently. The way that they approach that problem is impossible for a classical computer to do, but it is actually solvable for a quantum computer within a meaningful period of time—days or hours.

[Applied mathematics expert] Peter Shor back in the ’90s came up with an algorithm, now called Shor’s algorithm, that demonstrated that a quantum computer could, if it were sufficiently powerful, break these cryptographic algorithms. The problem is that since the ’90s, quantum computing has always been “at least 10 years away.” But now it feels like 10 years away is a lot closer than what 10 years away felt 20 or 30 years ago. That’s the crux of the issue.

When there’s a sufficiently powerful quantum computer, or cryptographically relevant quantum computer (CRQC), that’s when the quantum computer can break traditional, or currently-in-use, cryptography. A CRQC doesn’t exist yet. It might not exist for another 10 years, or it could become operational in one year. We don’t know how the technology will progress, but regardless, it seems to be progressing quickly. That’s why it’s right for us to be concerned about a quantum computer breaking encryption, and we should be thinking about it today.

Anything that is encrypted using public key cryptography, which is a lot of data, is potentially decryptable using a CRQC. It’s not instantly decryptable, it still takes time. Some incorrectly imagine that a CRQC can instantly decrypt everything all at once. That’s simply not true. But it can decrypt certain things that you put into it, in theory, much more quickly than a classical computer. And so, we do have to be concerned about the sensitive data that is encrypted. Now, obviously, someone with a quantum computer also has to get their hands on the data that they want to decrypt. This combination could cause problems.

Post-quantum cryptography (PQC) is a new kind of cryptographic algorithm that’s designed to remain secure even against quantum computer attacks. It doesn’t mean that the algorithm requires a quantum computer to use. You can still use PQC algorithms with a classical computer. It just means that when you run them on the classical computer, that a classical computer cannot break them, and neither can a quantum computer. To use post-quantum cryptography, we have to find all the places where we were using older cryptography and replace them.

There are two types of threats: one is “harvest now, decrypt later,” and the other is “trust now, forge later.” “Harvest now, decrypt later” is this idea that adversaries, and typically we’re talking about nation-states, are collecting encrypted data today and storing it with the idea that they are going to be able to decrypt that data later once they have a CRQC. Our data is flowing throughout lots of different networks when we access the internet.

The other issue is what’s called “trust now, forge later,” and that has to do with digital certificates or digital signatures. They’re how we verify identities on the internet. If you go to google.com, your computer knows that it’s google.com because there is a certificate on that website that your computer can [use to] verify that the data coming back from google.com actually came from Google and not an imposter. If attackers can forge those certificates using a quantum computer, then they can impersonate Google.

And if they can impersonate Google, they can impersonate other organizations as well. This is important because, for example, when your computer updates its software, when it downloads an update from Apple or from Microsoft, that update is cryptographically signed. That’s how your computer knows not to install an update that’s created by someone other than Apple or Microsoft. If someone can forge those certificates, they could potentially cause your computer to accept a malicious update.

Going back to the “harvest now, decrypt later” issue, there’s some data that we encrypt—this conversation, for example—as it runs throughout the internet, but it’s not particularly sensitive. There’s other data that flows throughout the internet that’s much more sensitive: defense contractors, operators of critical infrastructure, research institutions, financial institutions, national security companies—all of their data is much more serious and needs to be protected [for much longer]. Organizations that have that type of data should really have already started thinking about how they’re going to move to PQC algorithms to avoid the “harvest now, decrypt later” issue.

There are two things that we’re focusing on. The first one is an endorsement to help clients address the “harvest now, decrypt later” issue and the quantum computing risk. The second is creating awareness around and encouraging crypto agility.

When it comes to “harvest now, decrypt later,” the challenge is where cyber incidents that have happened in the past might not have been reported or understood in terms of their potential quantum risk implications. In the past, if a policyholder lost encrypted data, it may have been reasonable for them to conclude that they didn’t have to report anything to their insurance company, and that they wouldn’t have to notify the individuals whose data was contained in that encrypted data because the data is unreadable. That judgment may have made sense if you assume that data, once encrypted, is encrypted forever and never threatened by decryption.

Now, because of the prospect of quantum computing, that judgment is being called into question. If that encrypted data were to become decrypted years later, the policyholder is in a difficult position because the policy that was in force when their data was lost may not respond because the incident was never reported. And the policy in force today is also not going to respond because the policyholder already knew about the loss. What we are doing to support clients with this new endorsement is to protect the policyholder from being penalized for that prior knowledge of an encrypted data loss event that happened years ago, but now a quantum computer happened to decrypt that information.

The other thing that we are focusing on is crypto agility. For the longest time, cryptography has been really working in the background; once you set it, you can forget it. Now, it looks like we have to upgrade a significant portion of our cryptographic libraries [collections of tested software tools that enable cryptographic functions such as encryption and decryption], and the problem is, nobody really implemented the existing cryptographic libraries with the idea that they would need to be easily upgraded later.

Cryptographic libraries are scattered throughout different tech stacks that everybody uses, and they might not be documented everywhere. Nobody really knows, well, wait, what are we using? Where are we using it? What are we using it for?

Since we need to upgrade to post-quantum cryptography, we might as well do it in a way that permits us to upgrade again relatively easily. That means we have to know where our cryptographic libraries are. We have to know how they work. We have to make those libraries modular instead of hard-coded. Should a post-quantum algorithm be found to be vulnerable either by a quantum computer or a classical computer in the future, we will have a much easier drop-in replacement.

To be crypto agile, you would think about how you want to centralize everything on one library such that if you needed to change it out, you just change that one library. That’s the idea with crypto agility, make it easy to switch out algorithms, but there’s a lot of legwork that has to go into determining what you have on your system. If you’re going to upgrade your network router or your network devices or your hardware devices, you have to make sure that those devices will work with today’s systems, but they’ll also work a few years down the road when we migrate to PQC.

The other complicating factor is that businesses are constantly communicating with third parties. If businesses upgrade algorithms, they need to make sure that the third parties they work with also have upgraded their algorithms. That’s a coordination issue. Most organizations won’t be replacing their cryptographic libraries themselves, but they will be relying on third-party software vendors to do it for them. Both of those third-party coordination efforts need to work seamlessly to ensure that there’s no downtime. Taking systems offline is not going to be acceptable.

The important thing is to start on your crypto agility journey now. Organizations have long procurement timelines. The software and hardware that we adopt today very likely could be in use 10 years in the future. We need to be thinking about this issue.

Organizations that plan now, that work toward crypto agility, and that adopt PQC algorithms now are going to be in a much better position. Organizations that wait are going to be scrambling and doing things fast, and doing things when you have a tight deadline is going to be much more expensive and error-prone than doing it with a longer deadline. We need to be thinking about crypto agility and how we upgrade our cryptographic algorithms starting today.