The Quantum Leap: Navigating PQC Adoption in Today's Digital Infrastructure

The cryptographic foundations of our digital world are facing an unprecedented challenge: the rise of quantum computing. While large-scale, fault-tolerant quantum computers are still on the horizon, their potential to shatter current encryption standards necessitates a proactive shift towards Post-Quantum Cryptography (PQC). This isn’t a far-future problem; there exists a “harvest now, decrypt later” threat that demands attention today. This post explores the current state of PQC, its implications, and how it’s already making its way into the tools and infrastructure we rely on.

Understanding the Quantum Threat and PQC

Quantum computers, with algorithms like Shor’s Algorithm, promise to efficiently solve mathematical problems that are intractable for classical computers. This capability directly threatens widely used public-key cryptosystems like RSA and Elliptic Curve Cryptography (ECC), which are the bedrock of secure communication protocols such as TLS (Transport Layer Security).

To counter this, the cryptographic community has been developing PQC algorithms

• schemes believed to be resistant to attacks from both classical and quantum computers. The US National Institute of Standards and Technology (NIST) has been leading the charge in standardising these algorithms. One of the first to emerge from this process is the Module-Lattice Key Encapsulation Mechanism (ML-KEM), based on the Kyber proposal, now formalized in FIPS-203.

Key Exchange vs. Signatures: A Tale of Two Priorities

When we talk about securing TLS with PQC, it’s crucial to distinguish between two core cryptographic functions: key exchange and digital signatures.

Key Encapsulation Mechanisms (KEMs)

KEMs are used for the initial key exchange phase of TLS, where the client and server establish a shared secret to encrypt further communication. This is the most urgent area for PQC adoption. Attackers can record encrypted traffic today and decrypt it later once sufficiently powerful quantum computers become available. Protecting the confidentiality of today’s data against future threats makes PQC KEMs a present-day necessity.

Given these factors, the industry has prioritised a hybrid key agreement approach for TLS 1.3. This combines a classical algorithm (like X25519) with a PQC KEM (like ML-KEM-768). The most prominent hybrid scheme is X25519MLKEM768. This ensures that the connection remains secure as long as at least one of the component algorithms remains unbroken, providing a robust bridge to a fully PQC future.

Digital Signatures

Digital signatures are used to authenticate the server (and sometimes the client) through digital certificates. While PQC signatures are also important, the threat model is slightly different. The authenticity of a server is generally verified at the time of connection. We’re sure that, one day, quantum computers will be able to derive a private key for existing algorithms such as RSA, and use that to forge signatures. However, the immediate risk (an attacker recording sessions for retroactive decryption) isn’t the primary concern for signatures in the same way it is for KEMs.

Furthermore, current PQC signature schemes often introduce more significant overheads compared to their classical counterparts. This includes:

• Larger key sizes: ML-DSA (FIPS-204) and SLH-DSA (FIPS-205) keys and signatures can be substantially larger. For example, as detailed in the post-quantum signatures zoo, Dilithium2 keys can be around 3.5KB and signatures around 5.5KB, dwarfing traditional schemes.
• Slower operations: Signing and verification can be 10x-1000x slower.

The Rising Tide of PQC KEM Adoption

The good news is that PQC KEMs are rapidly gaining traction.

Cloudflare Radar provides compelling insights into this trend. Their data on post-quantum encryption adoption shows a significant uptick.

May 2023 - May 2024

May 2024 - May 2025

This adoption is driven by updates in key software libraries and applications. Here are some examples:

• Go: Version 1.24 (February 2025) of Go’s crypto/tls library introduced support for X25519MLKEM768 and, importantly, enabled it by default when no explicit override is set.
• Browsers:
  • Chrome 131 (November 12, 2024) transitioned to ML-KEM.
  • Firefox 135 (February 4, 2025) followed suit.
• OpenSSL: Version 3.5.0 (April 8, 2025) updated its default TLS keyshares to offer X25519MLKEM768 and X25519.

This is not an exhaustive list, but it shows the growing adoption of PQC KEMs following the standardization of ML-KEM.

PQC Beyond TLS: The Case of OpenSSH

The shift to PQC isn’t limited to TLS. OpenSSH, a cornerstone of secure remote access, also embraced PQC. OpenSSH 10.0 (released April 2025) introduced the mlkem768x25519-sha256 hybrid key agreement method as the default. This means that everyday SSH connections are increasingly being secured against future quantum threats.

Kubernetes: An “Accidental” PQC Adopter?

Given that Kubernetes components are written in Go, the updates in Go 1.24 have a direct and fascinating implication. Kubernetes v1.33 and later, which are built with Go 1.24+, inherit this default PQC KEM support. If the CurvePreferences are not explicitly overridden to exclude PQC options (which they generally aren’t in the core Kubernetes components), TLS connections to the API server can and do negotiate X25519MLKEM768 when connecting with a PQC-capable client.

This means many Kubernetes clusters are already more quantum-resistant than their operators might realise! At the same time, this transparent migration, may introduce some potential pitfalls. We will take a closer look at some of them in the next sections.

Check out my post on Kubernetes blog for more details.

The Go Version Mismatch: A Subtle Pitfall

While transparently moving users to PQC KEMs is great, it sometimes also introduces subtle issues. Go 1.23 (used by Kubernetes 1.32) had experimental support for a draft PQC KEM: X25519Kyber768Draft00. Go 1.24 (used by Kubernetes 1.33+) only supports the standardised X25519MLKEM768, the identifier X25519MLKEM768Draft00 was removed from the standard library.

At the same time, these two are not interoperable. If a client (e.g., kubectl compiled with Go 1.24) tries to connect to a server running the previous Go version (e.g., a Kubernetes 1.32 API server using Go 1.23), they won’t find a common PQC KEM. The connection will then typically downgrade to a classical ECC curve like X25519.

// Server with Go 1.23.x (supporting X25519Kyber768Draft00)
$ go1.23.9 run ./cmd/server

// Preferring PQC will downgrade:
$ go run ./cmd/client
2025/05/21 11:55:45 Received from https://localhost:8443:
Hello, World! Got TLS 1.3 request with CurveID: X25519 // Downgraded!

This silent downgrade can lead to a false sense of security, where PQC protection is expected but not actually in place. It highlights the importance of maintaining consistent Go versions across communicating components if specific PQC behaviour is relied upon.

Packet Size Limitations (The “tldr.fail” Problem)

A practical challenge with ML-KEM arises from its relatively large key sizes. For X25519MLKEM768, the KEM public key is 1184 bytes. This can cause the initial TLS ClientHello message, which carries the client’s key shares, to exceed the size of a single TCP packet (based on a ≈1500 byte link MTU).

Some older TLS libraries, network middleboxes, or even certain server implementations (incorrectly) assume the ClientHello always fits in a single packet. This can lead to dropped packets or failed handshakes. This issue, sometimes dubbed the “tldr.fail” problem, has been observed in various systems, including some related to Kubernetes ingress controllers and AWS network firewalls. It’s a reminder that cryptographic agility can have wider system implications.

The Slower Path for PQC Signatures

While KEMs are making strides, PQC digital signatures are on a slower adoption track for general use, particularly for building a PQC-secured Certificate Authority (CA) hierarchy.

The primary challenges remain:

• Performance and Size: As mentioned, PQC signatures are often larger and slower.
• Toolchain Maturity: Mainstream tools for CA management and TLS libraries often lack robust, production-ready support for PQC signature schemes.

The Go team has stated that ML-DSA (standardised in FIPS-204) is a high priority, but the earliest it might appear in the standard library is Go 1.26.

For now, experimenting with PQC signatures often requires specialised libraries or forks. Cloudflare’s CIRCL (Cloudflare Interoperable Reusable Cryptographic Library) and their associated Go fork (cfgo) provide implementations of algorithms like Dilithium. Using cfgo, one can generate certificates with hybrid signatures like Ed25519-Dilithium2. However, this is not yet suitable for widespread production deployment in most environments.

The Road Ahead

The transition to Post-Quantum Cryptography is a marathon, not a sprint, but significant progress is being made, especially for key exchange. The “default on” approach in influential libraries like Go’s crypto/tls and OpenSSL is accelerating adoption, making systems like Kubernetes more quantum-resistant, sometimes even without explicit configuration.

However, security practitioners and developers need to be aware of the nuances:

• The immediate priority is PQC for initial key exchange to protect against harvest now, decrypt later risks. Security leaders should not wait for attacks against legacy encryption to become practical and public.
• Version interoperability can be tricky, potentially leading to silent downgrades.
• Physical layer limitations like packet sizes can impact PQC deployment.
• PQC signatures are developing but are further from widespread, standardised deployment in common toolchains.

Staying informed and vigilant is key as we navigate this cryptographic evolution. The quantum leap is coming, and preparing our digital infrastructure is a continuous, collective effort.

Call to action

Do you need help with post-quantum cryptography adoption in your organisation?

Contact our cloud security experts today at [email protected] to discuss how we can help you.