Amidst all the noise around quantum computing, this blog aims to help organizations move beyond the hype and focus on practical steps developers and teams can take to prepare for what’s ahead.. Since publishing Separating FUD from Practical for Post-Quantum Cryptography, there have been a few notable developments. This post includes those updates along with actionable steps to prepare while avoiding the hype.

There 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. The step following selection is the integration of selected 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. Organizations 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. Organizations 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 Security Layer (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 prioritizing options. This prioritization 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 require 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.

Stay tuned for part two of this blog, which will discuss steps for organizations to take to integrate quantum computing within their network and systems.

__________________________________________________________________