Quantum computing presents a new frontier for technology, and a new set of security challenges, too. A sufficiently powerful quantum computer could break the public-key cryptography systems we rely on today, posing a significant risk to individuals and organizations.
Although that threat might be years away, building appropriate defenses can equally take years to build. Following our recent announcement of quantum-safe digital signatures in Google Cloud Key Management Service (Cloud KMS), we are excited to expand our quantum-safe capabilities. We are now announcing support for post-quantum Key Encapsulation Mechanisms (KEMs) in Cloud KMS in preview, enabling customers to begin their migration to a post-quantum world.
This new capability provides a critical building block to start protecting your applications from Harvest Now, Decrypt Later attacks. Adversaries can capture and store encrypted data today with the intention of decrypting it years from now, once a cryptographically-relevant quantum computer (CRQC) is available. This makes it crucial to protect sensitive data requiring long-term confidentiality, even if the quantum threat seems distant.
The challenge: Migrating to a post-quantum world
While the bulk of data is protected using symmetric encryption, asymmetric encryption is the key to exchanging those symmetric keys securely. It’s this key exchange process that’s fundamentally changing with post-quantum cryptography.
Migrating from classical asymmetric encryption to post-quantum KEMs is more than a simple algorithm swap; it requires a shift in architectural thinking. Developers will face two primary challenges: adapting to a new cryptographic paradigm, and managing new performance characteristics.
The most significant hurdle is that a KEM is not a direct replacement for traditional asymmetric encryption. With classical algorithms such as RSA, a developer often encrypts data they already have — for example, a symmetric session key they’ve generated.
A KEM completely inverts this model: the sender does not choose the shared secret. Instead, the secret is a fresh, random value generated as an output of the KEM’s encapsulation process itself.
This architectural shift means that you cannot simply replace an Encrypt() function call. To handle this complexity securely, developers should adopt a high-level standard like Hybrid Public Key Encryption (HPKE), defined in RFC 9180. HPKE is an extensible standard that can be used with different KEMs, and is available in libraries such as Tink to simplify the integration of post-quantum algorithms.
Second, developers will have to manage new performance characteristics. While the computational speed of post-quantum operations is often comparable to their classical counterparts, the size of public keys and ciphertexts is substantially larger.
This is not a trivial increase. We are often talking about an order of magnitude difference. For example, a standard ML-KEM-768 key is about 18 times larger than a P-256 key.
This size increase has direct implications for application performance, impacting bandwidth, storage, and memory usage. A successful migration requires architects to account for these larger payloads, particularly in resource-constrained environments like IoT devices.
A final challenge is the novelty of these algorithms. While the new standards have undergone intense scrutiny, they have not yet endured the decades of real-world analysis that classical algorithms have.
For this reason, for most general purpose applications, we strongly recommend using a hybrid approach. A hybrid deployment hedges against risks in the new PQC algorithms by combining a classical and a post-quantum algorithm. This ensures that any unexpected flaw in a new post-quantum algorithm, or its implementation, does not introduce a new vulnerability. It can help provide a safe and gradual transition to a post-quantum world.
Getting started with KEMs in Cloud KMS
To provide a flexible and secure path to quantum resistance, Cloud KMS now offers several KEM algorithms.
-
ML-KEM-768 and ML-KEM-1024: These are implementations of the Module-Lattice-based Key-Encapsulation Mechanism standard, published by NIST as FIPS 203. For customers who must comply with standards like CNSA 2.0, ML-KEM-1024 offers a higher security level, though at the cost of larger keys (1568 as compared to 1184 bytes) and ciphertexts (1568 versus 1088 bytes) which can impact performance.
-
X-Wing: For most general purpose applications, we strongly recommend using a hybrid approach. The X-Wing KEM, which combines the classical X25519 algorithm with the post-quantum ML-KEM-768 algorithm, provides layered defense against both classical and potential quantum adversaries.
Integrating these new quantum-safe KEMs into your workflows is designed to be a straightforward process using the Cloud KMS API. You can find detailed instructions and code samples in the official Cloud KMS documentation. Our underlying implementations will be available as part of Google’s open-source cryptographic libraries, BoringCrypto and Tink, to ensure full transparency.
The post-quantum road ahead
The migration to post-quantum cryptography is a marathon, not a sprint. This preview of post-quantum KEMs in Cloud KMS is a critical building block that can enable you to start preparing your applications for a quantum-safe future.
To make this transition easier, our open-source library Tink will provide support for Hybrid Public Key Encryption (HPKE) offering a more user-friendly way to integrate these KEMs in languages such as Java, C++, Golang, and Python. For some of these languages, this will be ready by the end of this year.
In the meantime, direct use of the KEMs in Cloud KMS is available for developers with deep cryptographic expertise. To provide more protection against Harvest Now, Decrypt Later attacks, Google Cloud is upgrading its infrastructure to use post-quantum cryptography for connections, with this capability expected to be fully available in 2026.
Our work in this space is ongoing. We are committed to keeping pace with developments in post-quantum cryptography, including future standards from NIST, and we plan to adapt to any changes in the quantum cryptanalytic landscape. While the industry continues to develop standards for hybrid digital signatures, we are actively monitoring progress and may offer support for such schemes as consensus emerges.
We encourage you to explore these new capabilities in Cloud KMS and begin the process of making your applications quantum-safe. We welcome your feedback and are eager to collaborate with you on your specific cryptographic needs.
