Advances in quantum computing threaten the cryptographic mechanisms long used by TLS. Google believes that the security of asymmetric cryptography used in TLS could be broken by quantum computers as soon as 2029 if research progress continues at its current pace.
To mitigate this risk, Google Cloud load balancers support post-quantum key exchange capabilities, designed to resist the theoretical capabilities of quantum computers. These algorithms were developed and vetted by the National Institute of Standards and Technology (NIST), and their use in TLS conforms with standards being developed under the IETF.
To learn more, see Post-quantum cryptography in Google Cloud.
How quantum computing threatens TLS security
Cryptographically-relevant quantum computers will be able to enable attacks against two critical components of TLS security: key exchange and authentication.
Attacks against key exchange
Cryptographically-relevant quantum computers will be able to break the key exchange algorithms used during the TLS handshake, revealing the symmetric keys that encrypt TLS sessions and exposing application-layer traffic in plaintext. This is true even for TLS connections that use perfect forward secrecy key exchange methods such as ECDHE. An attacker who records an entire TLS session today could even decrypt it years in the future when quantum computing capabilities become available, in what is called a harvest now, decrypt later attack.
Attacks against authentication
Cryptographically-relevant quantum computers will be able to break the keys used in TLS certificates or certificate authorities, allowing an attacker to falsely assert a client or server identity. Used with a man-in-the-middle attack, this could allow an attacker to see and manipulate the contents of TLS-encrypted sessions. Unlike attacks against key exchange, attacks against authentication cannot be done retrospectively against recorded traffic. However, attacks against authentication significantly threaten the integrity of web authentication.
Symmetric ciphers are not threatened
The symmetric cryptographic ciphers, such as AES-128, AES-256, and
ChaCha20, used to encrypt TLS sessions once the handshake and authentication
completes are not threatened by quantum computing.
Post-quantum key exchange
To mitigate the risk of harvest now, decrypt later attacks, we recommend that you enable post-quantum key exchange for connections between clients and load balancers.
Post-quantum key exchange is supported only for frontend TLS connections, that is, for connections between the client and the load balancer.
Post-quantum key exchange can be enabled for the following load balancers:
- Global external Application Load Balancers
- Classic Application Load Balancers
- Regional external Application Load Balancers
- Cross-region internal Application Load Balancers
- Regional internal Application Load Balancers
- Global external proxy Network Load Balancers
- Classic proxy Network Load Balancers
X25519MLKEM768 is the particular form of
post-quantum key exchange supported in Google Cloud load balancers. This
is a hybrid key exchange method, which means that it is secured by both
classical and post-quantum cryptographic mechanisms.
When post-quantum key exchange is enabled, the load balancer uses it when
connecting to clients that advertise support for TLS 1.3 and X25519MLKEM768.
Connections to clients that don't support TLS 1.3 or X25519MLKEM768 are
unaffected.
When post-quantum key exchange is enabled, the load balancer uses it when a
connecting client advertises support for TLS 1.3 and the X25519MLKEM768 key
exchange mechanism. Connections from clients that don't support TLS 1.3 or
X25519MLKEM768 are unaffected.
Enable post-quantum key exchange
You can enable post-quantum key exchange on your load balancer by using the
post-quantum-key-exchange setting in an SSL policy, either by attaching a new
SSL policy to your existing TargetHttpsProxy or
TargetSslProxy,
or by modifying an already attached SSL policy.
To learn more about how to create SSL policies with the post-quantum key exchange setting, see Create SSL policies.
We recommend that you enable post-quantum key exchange now, as it provides
immediate protection against harvest now, decrypt later attacks. Correctly
implemented clients are not expected to experience issues. However, if your
client application is incompatible, you can set post-quantum-key-exchange to
DEFERRED, which lets you delay enabling post-quantum key exchange
until October 2027, giving you time to make your application compatible.
Post-quantum key exchange rollout
Because the security protection offered by post-quantum key exchange
is important, Google Cloud will begin enabling it by default in
October 2026. This will affect load balancers that have no SSL policy attached,
or that use an SSL policy with no post-quantum key exchange setting. If
required, you can defer enabling post-quantum key exchange until October
2027 by using the DEFERRED setting.
The following timeline shows the planned rollout of post-quantum key exchange support for load balancers.
| Timeline | Post-quantum key exchange status |
|---|---|
| Now | Disabled by default, enabled only when set to ENABLED |
| After October 2026 | Enabled by default, disabled when set to DEFERRED |
| After October 2027 | Enabled always |