The rapid advancement of quantum computing promises unprecedented leaps in innovation, but it also introduces an emerging challenge for enterprise security. For CISOs, the threat is no longer a distant hypothetical. One of the most pressing concerns today is the “Harvest Now, Decrypt Later” (HNDL) strategy.
In an HNDL scenario, malicious actors record and store encrypted, sensitive customer data today with the intention of decrypting it years later once cryptographically relevant quantum computers become available. To protect the internet’s traffic and safeguard your data against future quantum decryption, we must begin transitioning to post-quantum cryptography (PQC) today.
To empower you to protect your own workloads at a global scale, Google Cloud is proud to announce post-quantum key exchange support for our Cloud Application and Network Proxy Load Balancers.
Hybrid post-quantum key agreement
We are introducing post-quantum key exchange support into our load balancers in the form of the X25519MLKEM768 hybrid key exchange. This method combines the finalized NIST ML-KEM standard with traditional encryption to secure the key exchange for TLS connections.
X25519MLKEM768 is a hybrid key exchange mechanism designed for TLS to provide security against both classical and potential future quantum computer-based attacks. Its hybrid nature comes from combining two different cryptographic algorithms:
-
X25519: This is a widely used and well-trusted Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm. It provides strong security against attacks from classical computers.
-
ML-KEM-768: This is a Post-Quantum Cryptography (PQC) algorithm, specifically a Key Encapsulation Mechanism (KEM) based on Module Lattices. It is designed to be resistant to attacks from quantum computers. ML-KEM is a standard selected by NIST.
The key exchange process simultaneously uses both X25519 and ML-KEM-768. The final shared secret established in the TLS handshake is derived from the outputs of both algorithms. This means that in order to break the key exchange and decrypt the traffic, an attacker would need to defeat both the classical protection of X25519 and the quantum-resistant protection of ML-KEM-768.
A permissive, seamless implementation
We designed this integration to be as frictionless as possible. Post-quatum key agreement support is implemented by adding a special parameter into the SSL policy on the load balancer frontend. Crucially, the load balancer will only use the post-quantum key agreement when a connecting client actively advertises support for it. This means the initial rollout is permissive rather than restrictive; enabling it does not generally present compatibility problems, even if you are operating with a mix of older clients that do not support post-quantum key agreement.
Phased rollout
Because Application and Proxy Load Balancers handle traffic for a massive variety of clients, we are executing this transition via a strategic, phased approach. While the risk of disruption is minimal, there is a small possibility that buggy clients advertising ML-KEM support might fail to tolerate it, or that network middleboxes intercepting traffic might fail the TLS handshake due to larger packet sizes. To ensure maximum stability for your workloads, the rollout will occur in three distinct phases:
| Staring dates | default behavior | SslPolicy controls | |
|---|---|---|---|
| Phase 1 (opt-in) | now | not enabled | elect to enable or defer |
| Phase 2 (opt-out) | October 2026 | enabled | elect to defer |
| Phase 3 (no opt-out) | October 2027 | enabled | defferal is no longer effective |
Phase 1 (opt-in) You can elect to enable post-quantum key agreement immediately via your SSL policy. This phase is designed to allow customers to thoroughly test compatibility with their clients and network middleboxes.
- Start date: now
Phase 2: (opt-out). The post-quantum key agreement will be enabled by default across load balancers. However, if you discover incompatibilities and need more time to adapt, you will have the option to temporarily defer (opt-out) the feature.
- Start date: October’26
Phase 3: (no opt-out). The post-quantum key agreement enabled by default. To ensure maximum security by default, post-quantum key exchange will be permanently enabled for all customers. At this stage, the option to defer the key exchange will no longer be effective.
- Start date: October’27
Call to action: Test post-quantum key agreement in your environment today
We strongly encourage you to test your solutions during the Phase 1 opt-in period before the feature is turned on by default. Testing early will help you verify that your client architectures and intermediate network devices can properly negotiate the post-quantum hybrid key exchange handshake.
To get started, you can easily create an SSL Policy with the post-quantum hybrid key agreement enabled using the Google Cloud CLI:
$ gcloud alpha compute ssl-policies create my-pqc-policy \
--profile RESTRICTED \
--min-tls-version 1.3 \
--region us-east4 \
--post-quantum-key-exchange ENABLED
$ gcloud beta compute ssl-policies describe my-pqc-policy --region=us-east4
fingerprint: XuZs5E3CPR0=
id: '3237496851298296512'
kind: compute#sslPolicy
minTlsVersion: TLS_1_3
name: my-pqc-policy
postQuantumKeyExchange: ENABLED
profile: RESTRICTED
region: https://www.googleapis.com/compute/beta/projects/myproj/regions/us-east4
selfLink: https://www.googleapis.com/compute/beta/projects/myproj/regions/us-east4/sslPolicies/my-pqc-policy
Once created, simply attach this SSL Policy to your existing load balancer’s target proxy to begin negotiating quantum-safe connections. By enabling post-quantum key agreement on your load balancers today, you can confidently protect your customers’ sensitive data against the threats of tomorrow.
For more details please consult documentation & release notes