Enterprise and SaaS Providers Prepare for Quantum Computing

Since my previous article on the topic of quantum - Separating FUD from Practical for Post-Quantum Cryptography - there have been a few notable developments that I would like to give an update on while also running through actionable steps that can be taken right now.

In the first part of this article, I'll look at the standards and protocol work that needs to happen behind the scenes. In the second part, I'll then turn to application integration and concrete steps enterprises and SaaS providers can take to prepare their own environments.

To start, here are six steps that must occur in order for enterprises and Software-as-a-Service (SaaS) providers to enable use of the specified algorithms or alternative solutions:

1. NIST has continued their important work leading the evaluation and selection of algorithms suitable to protect data against known quantum threats. See NIST for the current status of selected algorithms by cryptographic algorithm category.
2. After algorithm selection, the next step is the integration of those algorithms into protocol specifications. The Internet Engineering Task Force (IETF) is one of the key standards bodies supporting this integration work through a consensus driven process.
3. Developers implement updated specifications, including new cryptographic algorithm support, into libraries used by application providers.
4. Application providers integrate updated libraries into their applications and enable use of these updated cryptographic algorithms in products or applications.
5. Organisations update applications in cases where they manage the application or their SaaS provider updates the application to support the desired cryptographic algorithms. 
6. The enterprise or other application users can then select use of these cryptographic algorithms. Organisations update their browsers and other clients, which will allow for the negotiation to successfully select a cryptographic algorithm believed to be safe from known attacks involving quantum computers. 

The standards integration process

The IETF has begun work toward supporting quantum safe cryptography and formed the Post Quantum Use in Protocols (PQUIP) working group, supporting experts that span cryptographers and protocol designers to developers and operators in their efforts to collaborate on the selection and specification required for successful integration of these new algorithms.

The quantum-safe algorithms or mechanisms have different properties than prior cryptographic algorithms used in protocols, thus the agility built into existing protocols to adapt to integrate new cryptographic algorithms was not adequate. PQUIP has published a terminology document to assist in discussions by establishing common terminology.

The work of the IETF considers algorithm agility in each applicable standard, which may take place in the protocol focused working groups, such as the Transport Layer Security (TLS) working group.

Algorithm agility planning

Developers of libraries are engaged in these discussions, as are application, browser, and hardware security module (HSM) vendors. They are currently working through pressing questions such as whether or not a protocol should include support for a hybrid approach or directly move solely to a pure quantum algorithm for their implementations.

Hybrid approaches vary with one example using current day key establishment algorithms (e.g. ECC and RSA) with the results concatenated. The assumption with this hybrid approach is that at least one of these algorithms will remain secure, thus ensuring the security of the generated key. The uncertainty associated with the new quantum-resistant algorithms is driving the desire to support the hybrid approach in addition to pure quantum cryptographic algorithms.

Sometimes security problems are identified in new algorithms, which occurred during the NIST Post-Quantum Cryptography (PQC) selection process. Problems may also emerge in implementations of those new algorithms. Having alternate algorithms is desirable in case one of the algorithms has flaws. The ability to easily switch between the implemented algorithms is known as cryptographic algorithm agility, or just crypto agility. Without crypto agility, the amount of time to fix an implementation and roll it out can be significant. If a problem is found with one of the newer algorithms, an implementation may switch to a hybrid approach.

Additional hybrid approaches have been proposed and developed including XWing and Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), used in IPsec. The latter, "allows multiple key exchanges to take place while computing a shared secret” for this hybrid approach.

Understanding which algorithms to select

It is likely that every protocol will include support for both pure quantum and hybrid solutions. For instance, TLS library implementations may support both hybrid and pure quantum algorithms to ensure agility within the protocol from among a supported and approved set of algorithms. If a problem is found with either a hybrid or pure quantum cryptographic algorithm, the respective Internet Assigned Numbers Authority (IANA) table for the protocol will be updated (in time) to reflect the consensus view on which algorithms remain recommended.

From the recommended list of cipher suites for any given protocol, there are typically supporting resources to aid in the decision process for selecting and prioritising options. This prioritisation or guidance may be from a national standards body such as NIST or could also be in the form of a best practices document on implementing a protocol such as BCP195: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).

Protocol integration

In discussing browsers, the transport security protocol used with many applications that is top of mind is TLS. TLS is used to protect application transport for numerous protocols including HTTP, MLS (e.g. RCS messages), MQTT, SMTP, etc. TLS is an integral part of the QUIC protocol design, supporting streaming media, HTTP/3, and other sessions that benefit from improved performance. It should be noted that only TLSv1.3 and higher will incorporate support for quantum safe cryptographic algorithms. For application providers, understanding the minimum version of a protocol that supports quantum safe cryptography is an initial step towards incorporating these capabilities when appropriate. Planning upgrades to protocol versions that will support quantum safe algorithms is a step that should be in progress today.

Encryption in other transport protocols requires consideration and working group participants are actively engaged in a similar process to the TLS working group. These include Ephemeral Diffie-Hellman Over COSE (EDHOC), a transport intended for constrained devices, and IP Security (IPsec), which tunnels IP sessions between hosts and also gateways such as routers or firewalls. Each of these protocols has defined sets of approved cipher suites or cryptographic algorithms in an IANA registry. The approved list changes over time based on known vulnerabilities and emerging solutions.

Considerations on support extends to key management systems and infrastructure such as public key infrastructure (PKI), cryptographic message syntax (CMS), and key management interoperability protocol (KMIP) that follow a similar process of integration first at the standards levels, then library support, prior to application integration. Similarly, formatted data in schemas such as JSON, CBOR, and XML have defined cryptographic functions including encryption and digital signatures to operate over defined data, sometimes tokens that will require updates. The JOSE working group is responsible for the digital signature and encryption specifications in token formats such as a JWT in JSON and the COSE working group for the equivalent functions for CBOR. The agreed-upon and recommended solutions will be published to the respective IANA libraries in time for JOSE and COSE functions.

All of this work at the standards and protocol layers can feel quite removed from day-to-day operations, but it is what makes a safe and orderly transition possible. With those foundations in place, the next question is how these capabilities surface in real applications and services, and what that means for the organisations that rely on them.

Application integration - enabling organisations to transition

Once integrated into applications, the ability to use these quantum safe algorithms is possible for an organisation. In SaaS applications, the provider will integrate and test prior to rolling out support across their customer base. Assuming browser-based access, this transition should be seamless for the end user who would have updated browsers that support the new cryptographic algorithms well in advance of the SaaS provider rollout. The application end has the opportunity to select among the supported algorithms from the recommended lists in the respective protocol parameter IANA registry.

The threat of Shor’s algorithm in store-now-decrypt-later attacks for asymmetric cryptography remains, which is why this work remains the priority. Since my prior blog was released, research reduced the threat of Grover’s algorithm to symmetric cryptography, so those updates are a lower priority than solutions and protocols using asymmetric cryptography. However, since existing algorithms such as AES-256 are available and integrated into libraries, this transition can occur easily while waiting for specifications and implementation support of asymmetric algorithms. 

SaaS and other application providers will have more preparation than the enterprise as they will integrate updated versions of libraries that incorporate quantum safe cryptography into their solutions. Protocol standards and libraries implementing those standards will likely support pure quantum and hybrid cryptographic algorithms to provide quantum safe cryptography. Application providers will make decisions on whether to support a hybrid approach or move directly to quantum safe algorithms, determining if they would benefit from additional agility in the event that an approved quantum safe algorithm was deemed vulnerable. With support existing in standards and libraries, agility will be inherent at the protocol layer. The complexity in these decisions for application owners will require understanding concerns for interoperability with other products where necessary. For example, browser decisions on cryptographic support and inclusion impact the decisions of application developers for which their application is accessed using a browser. For less widely used clients, application developers will need to consider agility and how that will be supported in their applications.

Steps for organisations

Organisations have a few actions they can take to prepare their networks for quantum computing, with a transition that should feel fairly seamless. With some basic preparation, the transition will not require substantial skill sets beyond asset management that includes maintaining inventories of applications and their applications’ use of encryption in transit, at rest, and in execution, and identifying priority changes to make. The transition will take time as the steps listed in the introduction follow an important process to achieve consensus on algorithms and approaches, followed by testing implementations.

The steps for organisations are far simpler and while some preparation is possible, organisations will have to wait on the standards process and then application integration. Here are 3 steps an organisation can take to prepare and begin their transition to quantum safe cryptography:

1. Asset management is the first step here and in every control framework. This includes inventory of data and the current cryptographic solutions, and cryptographic keys in use. If opportunities exist to upgrade to protocol versions that will support quantum safe cryptographic algorithms, those upgrades should be planned appropriately.
2. Controls assessment on data protection, understanding if your controls are appropriate for both the sensitivity and business criticality levels.
3. Supplier management should extend to include timelines for libraries and protocol versions in products used by your organisation, assessing support for quantum-safe cryptography. This will take time.

For all organisations, procurement should require verification of quantum safe cryptography support in hardware and firmware purchased today. Major hardware vendors have already made this possible. Hardware lifetimes for some systems and devices can be as long as 1-2 decades, and this is a place where you’ll need to ensure your vendors are prepared today so that you can gradually end-of-life systems and devices that cannot be made quantum safe against the decryption attacks possible with quantum computing. Existing legacy hardware, constrained devices, including IoT and lightweight HSMs may need to consider alternate solutions when Adapting Constrained Devices for Post-quantum Cryptography.

Planning application support

For application-level changes, there is time before any actions can be taken by most organisations as the standards evolve to support the newly selected cryptographic algorithms and mechanisms. Application developers can follow directly along with the IETF discussions and follow guidance from NIST as well as other sources such as the UK NCSC who have published helpful next step documents. 

Support available today in web applications!

Announcements as well as software updates will continue to emerge, with the web being an early candidate. Announcements with timelines from Akamai and the existing capabilities from Cloudflare demonstrate feasibility to migrate this year since browser support exists for one algorithm. The content delivery networks host upwards of 70% of all web traffic and have skilled teams supporting these transitions, enabling this capability in 2025.

Summing up

Taken together, these developments show that the move to quantum safe cryptography is already underway, rather than a distant, one-off event. By understanding where you depend on cryptography today and engaging early with your application and infrastructure suppliers, you can make that transition largely seamless for users while materially reducing long-term risk.