With their vast increase in computing power, quantum computers promise to revolutionize many fields. Artificial intelligence, medicine and space exploration all benefit from this technological leap — but that power is also a double-edged sword. The risk is that threat actors could abuse quantum computers to break the key cryptographic algorithms we depend upon for the safety of our digital world.

This poses a threat to a wide range of critical areas. Fortunately, alternate cryptographic algorithms that are safe against quantum and classical computer attacks already exist.

The National Institute of Standards and Technology (NIST) recently announced such alternatives following the completion of the third round of the post-quantum cryptography (PQC) standardization process. In total, four PQC algorithms have been selected by NIST, one for key establishment (CRYSTALS-KYBER) and three for digital signature (CRYSTALS-Dilithium, FALCON and SPHINCS).

While this is encouraging, the major challenge ahead is transitioning today’s encryption implementations to quantum-safe encryption (QSE). This article describes how quantum computers impact encryption and outlines an approach for guiding organizations to transition to QSE.

Impact on asymmetric encryption

Encryption algorithms typically protect sensitive data in storage, transit or use. For instance, processes such as securing data communications, signing financial transactions in blockchain and signing software for secure distribution all use asymmetric encryption. It’s now becoming clear that asymmetric encryption algorithms based on factoring large integers (e.g., RSA) and those based on discrete logarithms (e.g., Diffie-Hellman) will need to be replaced by quantum-safe alternatives such as CRYSTALS-KYBER and CRYSTALS-Dilithium.

Effective security strength (shown in Table 1 below) suggests that the strength of RSA and elliptic-curve cryptography (ECC) is weaker or comparable to advanced encryption standard (AES) on a classical computer, but is null on a quantum computer. This is because Shor’s algorithm can perform integer factorization in a polynomial time.

In other words, what requires millions of years with classical computers would only take minutes on a large-scale quantum computer.

Impact on symmetric encryption

Unlike asymmetric encryption algorithms, symmetric encryption algorithms do not face an existential threat. One still needs to perform a brute-force attack to break them. However, a large quantum computer running Grover’s algorithm could provide a quadratic improvement in brute-force attacks on symmetric encryption algorithms such as AES. This translates into a need to double the key size to support the same level of protection.

For AES specifically, this means using 256-bit keys to maintain today’s 128-bit security strength, as depicted in Table 1.

Table 1: The effective security strength of key encryption algorithms.

Transitioning to QSE

Given the ubiquitous use of cryptography in our digital world, the transition to QSE will be a large endeavor for global organizations. While not an exhaustive list, Table 2 gives a good indication of the number and type of systems and applications that need to change across the four core cryptographic areas: key exchange, digital signature, authentication and data encryption.

Table 2: Example use cases that require a transition to QSE.

An approach for transitioning to QSE

As with any major endeavor in cybersecurity, the transition to QSE will involve people, processes and technology. Because the technology in this area is still emerging, our focus today is on the technology required for helping organizations transition to QSE. A solution in this space ought to cover four pillars: find, assess, prioritize and remediate.

Figure 1: The four pillars for transitioning to QSE.

Pillar 1: Find

The first objective is to collect the inventory of cryptographic assets used by the organization. This includes algorithms, keys, certificates, protocols and libraries. It typically consists of a scanner capable of scanning an application, a host or a network and an inventory of cryptographic assets.

To be effective, the scanner technology needs to meet two key criteria: breadth and automation. Breadth is to ensure that the scanner can support the various flavors of operating systems, networks, file systems and programming languages (for applications) that are in use in any organization today. A gap in the support here would mean a blind spot in the cryptographic inventory. Automation is to ensure that the scanners can easily be deployed within the organization. Integrations with tools such as Tanium typically address this concern.

Pillar 2: Assess

The objective of this pillar is to look for vulnerabilities across the collected cryptographic inventory. We believe that the need to transition to QSE provides an excellent opportunity to modernize encryption implementation overall. Therefore, the vulnerabilities this pillar uncovers would not be limited to finding usages of algorithms that are not quantum-safe. They would include any cryptographic vulnerabilities.

This pillar discovers two main types of vulnerability. The first type represents vulnerabilities that do not require an application change to fix them. These include rotating expired encryption keys, renewing expired certificates, restricting a keystore’s file permission and others. The second category represents vulnerabilities that require an application change to fix them.

For example, an application that creates digital signatures using RSA must be changed to use a quantum-safe alternative such as CRYSTALS-Dilithium. Similarly, an application that establishes a key exchange protocol using Diffie-Hellman (DH) must be changed to use a quantum-safe alternative such as CRYSTALS-KYBER.

Pillar 3: Prioritize

This pillar aims to prioritize the vulnerabilities discovered based on risk so that the organization addresses the highest risks first. This risk-based prioritization requires enrichment data.

Consider the following example: the “assess” pillar discovers that two databases, A and B, are encrypted with two encryption keys, K1 and K2, which must be rotated. Additionally, suppose that K1 and K2 are each stored in a local keystore for which the file permissions must be restricted.

Which issue should the organization address first? It is hard to tell without enrichment data. Suppose that database A contains classified information, while database B contains public information. The data classification information is an example of enrichment data. The “prioritize” pillar uses this context to prioritize fixing the issue for database A, which poses a higher risk.

Pillar 4: Remediate

Lastly, the “remediate” pillar automates the remediation of those prioritized issues. The remediation procedure would be different depending on whether the issue requires an application change or not. For issues that do not require an application change, this pillar integrates with external systems to drive a resolution. For example, integration with a ticketing system such as ServiceNow would pass the issue on to the appropriate stakeholders for resolution. Similarly, an integration with a certificate management system would automate the renewal of an expired certificate.

For issues that require an application change, we propose moving away from the classical model where encryption is tightly coupled with the application to a new paradigm where encryption is consumed as a service. Under this new paradigm, the application would consume the cryptographic functions it needs from a cryptographic service provider through a set of application programming interfaces (APIs) that abstract away the encryption details from the application. Where a change is needed, only the cryptographic service provider must be updated. This saves time and resources for the organization as the application does not need to change. We refer to this concept as crypto
agility.

Deploying PQC algorithms in production environments

While NIST has announced the PQC algorithms selected for standardization, the organization will not announce the actual PQC standard before 2024. Additionally, the selected algorithms will undergo significant updates before the standard is published. This begs the question: Should organizations go into production with the PQC algorithms now?

The guidance from NIST and the Cybersecurity and Infrastructure Security Agency (CISA) is that organizations should wait until the official release of the PQC standard to implement the PQC algorithms in a production environment. However, NIST and CISA also recommend that organizations start preparing for this transition now. We share this view and recommend that
organizations take the following steps:

• Educate the organization’s workforce about the upcoming transition.
• Implement the find, assess and prioritize pillars to build an inventory of cryptographic assets and prioritize vulnerabilities.
• Remediate any issue that is not related to switching quantum-unsafe asymmetric algorithms with their quantum-safe alternatives. For example, it is fine to change any usage of AES 128 to AES 256. This is good practice irrespective of quantum computing.
• Test the new PQC algorithms in a lab environment. However, wait until NIST publishes the PQC standard before deploying them in production environments.
• Validate and test any products, systems or applications you acquire from a third-party vendor to ensure they incorporate the PQC standard when it is published.

The future requires crypto agility

Encryption is the bedrock of our digital world. While the transition to QSE will be a major endeavor for organizations across the globe, this is also an excellent opportunity to modernize and fix current encryption implementation. Crypto agility will enable organizations to react faster to cryptographic vulnerabilities and future changes to cryptographic standards.