Schedule a Demo
Blog April 9, 2020 Cryptographic Keys, encryption, Hash Algorithms, quantum computing

Are You Preparing for Quantum?

by Mark B Cooper

Quantum supremacy is looming…some year in the future. However, contrary to what you may have heard, the advent of quantum computing won’t spell the end to encryption as we know it. That is, if enterprises take the necessary steps to prepare for a post-quantum future.

Enterprises must begin the process of assessing their current systems, software and appliances now, otherwise these systems will become impediments and potentially open the door to countless vulnerabilities. Once the weak links are identified, it will be important to begin working with vendors to determine their roadmap and timeline for post-quantum integration.

I hosted the webinar, Quantum Preparedness: Take Action Now Before the Crypto Sky Falls and enjoyed the active participation. Here are some of the questions I was asked, and my not-so-very-brief answers:

What industries are the most risk when it comes to quantum.

This really isn’t necessarily isolated to one industry. Y2K was something that a lot of people could dismiss if they were outside of the financial and banking sector. Just about every industry today is using encryption or signing in some way in their business. Generally, anyone that is storing information either for customers, in the financial space, healthcare, technology, or even in the manufacturing space where you have something proprietary, there is more likely a very high probability that someone will be interested in your information. The reality is that just because a quantum computer is capable of breaking encryption doesn’t necessarily mean that someone is going to look at your stuff. But if you are the holder of information where people are constantly trying to find details, somebody is going to be very motivated to take a quantum computer and look at your data.

Resources are an issue at my organization, what are the top things we should be doing now to prepare?

Every organization is busy with a thousand other fires. An organization can start with one single evangelist, you don’t need a massive project team. This can start with you. Figure out the systems you’re responsible for. Begin creating a sheet of what types of keys you have and the crypto agility. Begin evangelizing and sharing it with your colleagues and others within the company and adding information where you can. A lot of the details you need aren’t necessarily a forced multiplier of colleagues. Sometimes it’s a matter of looking through the UI of the product or consulting the documentation or opening a support case with the manufacturer. Sometimes, the information about the system may already be there that can really help you. There are a lot of people already tracking what’s happening in the quantum space. Find a trusted source, figure out how they are tracking the quantum computing updates, and make sure you are checking with them regularly. Make sure that you have found a trusted source to do the heavy lifting for you.

Can you please comment on the recommendations in CNSA (former Suite B) in relation to quantum preparedness? Is RSA 2048 not adequate?

Right now, the best that NIST can do is have a crystal ball to try to figure out where quantum supremacy is likely to reign. It’s still RSA-2048 at a minimum and SHA-256; technically SHA-224 on the signature side is still considered acceptable commercial practices. There are expectations that those key sizes and hashing algorithms will continue to grow. But at this point, NIST hasn’t really pinpointed a date for transition. There’s not necessarily an algorithm that’s been selected by NIST to migrate to. It’s on their roadmap, but there’s really not a set of encryption and signature algorithms you can move to today. It really is about preparedness.

Do you think Microsoft, IBM, Google, etc. will be selective in who they allow to purchase time on the quantum computing web?

I don’t think they’ll be selective if you’ve got an account or a credit card and you’re willing to pay the charge. What we’ve seen with any other type of service is everything can be put to malicious use. We’ve certainly seen from computing resources and communications that the inherent belief is that you’re up to something that’s legitimate until proven otherwise. I don’t necessarily expect these cloud providers to do some type of vetting and verification of who’s using their quantum computing resources. If you’re paying your bills and you’re crunching away, they shouldn’t have an idea of whether you’re sitting there trying to crack large prime numbers or you’re doing some molecular healthcare research. They shouldn’t know what kind of data you’re working with. No, I don’t think they will be selective. A dollar is a dollar.

Could keys be generated and stored in HSMs to resolve this issue?

HSMs are not actually really changing the scenario at all. If we think about what an HSM is responsible for doing, it’s the cryptographic engine that is providing some random number generation; it’s creating the prime numbers that are used to create the private and the corresponding public key. When the cryptographic operations occur, they happen inside of the HSM. But in order for asymmetric encryption to work, the other side of the party has to have the public key that goes along with that. That’s either inside of the certificate that’s shared, such as a TLS certificate, or it’s exchanged as part of that communications process. When we talk about quantum supremacy and breaking encryption, it’s essentially the public key that is really just a factor of the private key. If you can take the public key and factor the two prime numbers that were used to multiple together to get the public key, you now have a private key. It doesn’t matter that the private key was generated or stored or processed inside of an HSM, and theoretically shouldn’t move – it hasn’t moved – we have just recomputed what the private key is. And that’s why there is a significant challenge here. It doesn’t matter how secure you keep that private key, it’s directly related to the public key and if I can reverse engineer your private key, then an HSM doesn’t make any difference.

Can you talk a little more about symmetric encryption algorithms?

Symmetric is nice in that the current model says that AES-256, one of the most common types of symmetric keys is likely to be impervious to quantum computers. The whole issue here is something called Shor’s algorithm, which really goes about how can we figure out what the private key is that corresponds to a public key, the asymmetric side of things. Symmetric is a single code – whether it’s a password or passphrase – that encrypts and decrypts the information. The code should never be exposed so there is no function to have a quantum computer to go against. Really, its only option is to brute force it, meaning to take that data and sit there and churn and try to figure out what that password is. That’s very different than factoring. Factoring is: here’s the public key, figure out the two numbers that were used to be multiplied together to get it. That’s a mathematical formula that’s much easier for a computer to do. Symmetric key, the encryption itself will likely be very secure. The challenge, however, is symmetric keys: the passwords have to be kept private. So, if I’m going to use symmetric encryption to transfer something to someone else, how am I going to get them the symmetric key so they can de-encrypt it. One thing I can do is use a temporary asymmetric key pair to transmit it, so they can give me their public key and I can take this symmetric key for this thing that we’re exchanging and encrypt it with their public key and send it over to them so they are the only ones that can decrypt it. Now if I can have a quantum computer intercept that conversation, back to the public key of the recipient, now I can see the symmetric key that was used and get to the data. So, symmetric keys are really resistant when it comes to quantum computers but now this sharing and storage and the long-term retention of the symmetric key comes into play of how am I going to do that securely because otherwise, I’m going to have one symmetric key protecting another symmetric key, protecting another symmetric key…where does it end? So, there’s a whole other set of problems that are there.

As 32-bit hardware is rapidly vanishing from servers, clients, and mobile devices, is it time to start using SHA-512?

It’s an interesting thing. When we do deployments and working with customers, one of the major things that we come up with is we’re all in the SHA-2 boat and the primary algorithms in the SHA-2 space, SHA-256, SHA-384, and SHA-512. Technically, NIST right now says the bottom is SHA-224; most operating systems like Windows don’t even have a SHA-224 algorithm for hashing signatures. SHA-256 is really the bottom of the barrel, acceptable practice – you’re not going to be scolded for doing that, but you’re not going to get any kudos. SHA-512, there’s actually enough rumblings that are out there around compatibility, and the challenge is most of us don’t have environments that are completely new. We can’t point to every appliance, operating system, device, application, and environment and go everything here is five years or newer – and in that case, we can do SHA-512. When we do things like IoT where we have a very defined network of devices, things that we’re manufacturing and we have a very good understanding of the cryptographic abilities, SHA-512 absolutely not a problem there. Where we find the sweet spot, SHA-384, that seems to have a good compatibility, puts us one step ahead of SHA-256. Frankly, the expectation is honestly SHA-2 most likely will be end-of-life or made irrelevant by the quantum supremacy issue. We do expect they’ll be a number of years there. NIST is already actively working on replacements for the SHA because hashing and signatures need to evolve as well. So, when you look at NIST and the quantum algorithm selection process they are going through, there are some that are just for encryption and some that are for signing. I think for the time being, most enterprises will get the biggest bang for the buck from SHA-384. I don’t necessarily think that the heartache of SHA-512 is going to make you any more quantum resistant and probably introduces more problems than it’s worth for most environments.

Do you think that the first practical crypto-breaking quantum computer will be announced or kept secret by a nation state?

If we have learned anything from history, there’s a lot of stuff that’s happening that we don’t hear about for years later. While we may hear that Google and NSA are collaborating on quantum computers, I think we would all be a little nearsighted to assume that that’s the only government and the only place that things like this are happening. I suspect that there will be some private developments in the quantum space, at least several years ahead of what we’re seeing in the public space. That’s why this is a little difficult. In getting prepared for this, we can’t just benchmark ourselves off of what we’re seeing from Google and NSA.

Do you have a question that didn’t get answered? Send me an email:  thepkiguy@pkisolutions.com. Did you miss this quantum readiness webinar? No problem. You can listen to it anytime: https://www.pkisolutions.com/webinars/. We’ll be hosting several webinars this year — keep checking back https://www.pkisolutions.com/webinars/

Related Resources

  • Blog
    October 31, 2022

    Field Report – Mitigating PKI Template Risks for Ephemeral Workloads and Desktop

    encryption, PKI, PKI Spotlight
  • Blog
    July 26, 2021

    Cyber Attacks, Code Signing, and the Digital Supply Chain

    Code Signing, Hash Algorithms
  • Blog
    June 21, 2021

    Handling X509KeyStorageFlags in applications

    C#, Certificates, Cryptographic Keys

Mark B Cooper

President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.

View All Posts by Mark B Cooper

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *