There is sufficient evidence today that quantum computing will change the landscape of internet security. While there isn't a clear timeline of when quantum computers will achieve the practical ability to attack current cryptography, enterprises will need to be prepared for that reality. The sooner the better, because any data that is being intercepted now has the potential of being decrypted at that point. IBM has been tackling this threat head on, with Quantum-safe software solutions to discover vulnerable areas of applications, observe cryptographic posture, and transform deployed solutions.
Part of the roadmap for quantum readiness lies with IBM Cloud. Since 2018, IBM Cloud has been working closely with Cloudflare to bring high performance application security natively into IBM Cloud. The IBM Cloud Internet Services (CIS) offering enables businesses to protect their applications on the edge, with advanced DDoS mitigation strategies, content delivery networks, and highly customizable firewalls. CIS can accomplish all of this by acting as a reverse proxy in front of customer's origin web servers.
Introducing: Post-Quantum Cryptography on IBM Cloud Internet Services
In 2022, after a 6-year long competition spanning 82 algorithms, NIST selected CRYSTALS-Kyber as the draft standardized algorithm for general encryption. This algorithm for key agreement (now named ML-KEM) was chosen due to its relatively small encryption keys and high performance characteristics. Now that the public draft standards are in place, the industry can begin implementing long-term solutions.
Successful adoption of post-quantum cryptography happens on multiple levels. These areas of focus are the client-to-edge connection, the network edge, and the edge-to-origin connection. Ideally, all three of these areas will be using post-quantum encryption to ensure the end-to-end lifecycle of the request is secure.
Beginning with client-to-edge connections, support needs to exist on both the browser and on IBM's edge. Chromium paved the way when it enabled post-quantum support by default in August 2023, which will trickle down into support on Chrome, Opera, and Edge. Firefox is now following this example and allows users to enable Kyber in their advanced settings. Cloudflare research has posted a helpful list of software support for post-quantum key agreement, which includes non-browser clients and servers.
From the network edge, support was enabled to accept X25519+Kyber requests in October 2022. This puts CIS customers in a great spot, because they will already be prepared for widespread adoption of post-quantum encryption from the browser. On the edge where the reverse proxy lives, requests are routed through an internal network. Most of these connections are already set to use post-quantum cryptography, and Cloudflare is targeting complete adoption of ML-KEM on all internal connections by the end of 2024.
The final link in the chain is the edge-to-origin connection. This is where outbound requests are made from CIS to the customer's origin server. IBM and Cloudflare are carefully rolling out support for outbound connections to CIS customers, which is expected to conclude by the end of the year. However, customers can skip this roll-out phase and choose to opt-in or opt-out of post-quantum using the CIS API.
To take advantage of this outbound post-quantum support, customers should inspect their origin server and ensure that they are using a configuration that supports TLS 1.3 and the ML-KEM post-quantum key agreement.
Both IBM Cloud and Cloudflare recognize the importance of providing quantum-safe readiness for their customers. For this reason, post-quantum cryptography will be made available for CIS customers at all plan levels at no additional charge.
Hybrid Key Agreement on the Hybrid Cloud
As stated earlier, ML-KEM is the NIST standard key agreement algorithm for post-quantum cryptography going forward. ML-KEM is on track to eventually replace the widely-used X25519 Diffie-Helmman key agreement mechanism. When ML-KEM is fully adopted, it will be to everyone's benefit because it can provide a big performance boost over X25519 even with a larger key size.
However, it is possible that ML-KEM might be broken in its early days of becoming a proven security standard. For this reason, ML-KEM is not being utilized alone for requests enabled with post-quantum. It is being combined with the current X25519 mechanism to form X25519Kyber768Draft00. By combining the two algorithms, the advantages of post-quantum encryption and the trust of X25519 are realized. This marriage has already prevented attacks against early implementations of ML-KEM by itself, such as KyberSlash.
Post-Quantum Trust
There are actually two parts to adopting post-quantum cryptography. After adopting ML-KEM, the second part is migrating our signatures and certificates to verify that our connections are going to the right place. This issue poses less of an immediate danger than key agreement, because trust is not vulnerable to "store and decrypt later" attacks. We care only about verifying the legitimacy of the connection in the moment. However, this migration will be much more challenging than adopting the new key agreement strategy.
In NIST's competition for post-quantum standardization there were three selections for signature algorithms. These are ML-DSA (Dilithium), SHL-DSA (SPHINCS), and FN-DSA (Falcon). All three signature algorithms have very large key and signature sizes compared to their non-quantum alternatives, with various tradeoffs between size and performance.
In reality, it might not be wise to start adopting any of these draft standard signature algorithms from NIST right away, because the increase in signature size could result in a large increase in the amount of traffic for any application. There are many signatures involved in visiting even a simple website; from the CA certificate chain, to the WEB PKI signed certificate timestamps, to OCSP staples. These larger certificate chains can also create issues in establishing connections reliably in the first place.
There are additional signature schemes being proposed to the NIST standards that do have better size constraints than the current selections, but it has yet to be seen if these can be broken. Because of the uncertainty around post-quantum signatures, many clients don't support these kinds of certificates yet. The path forward may not be clear yet for post-quantum trust, but there are many promising strategies being evaluated. Support for whichever method is selected will be swiftly adopted.
Time for Action
I urge readers to review their posture for post-quantum, and even cryptography in general. It's never a bad idea to take stock of what software you are using and where your vendors are in terms of support. We expect NIST to finalize the draft standard for key agreement soon, but it is worth your while to start working towards this readiness, even before the standards are finalized. Your business may already be able to take advantage of post-quantum key agreement using IBM Cloud Internet Services.
Learn More
For more information on IBM and Cloudflare, visit Cloudflare on IBM Cloud.