Google Cloud recently announced a new capability in its Key Management Service (Cloud KMS), introducing support for post-quantum Key Encapsulation Mechanisms (KEMs) in preview. With the support of Google Cloud, organizations can prepare for the inevitable threat posed by cryptographically relevant quantum computers (CRQCs), which could potentially break today’s standard public-key cryptography.
The company aims with the new feature to specifically address “Harvest Now, Decrypt Later” attacks, where adversaries capture and store currently encrypted data with the intent of decrypting it years from now once a powerful quantum computer is available. By providing quantum-safe KEMs, Cloud KMS allows organizations requiring long-term data confidentiality to begin their migration today.
Brent Muir, a Principal Consultant at Google Cloud, commented on LinkedIn, stressing the importance of immediate action:
Although these attacks are still theoretical in nature, 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 migration from classical asymmetric encryption (like RSA) to post-quantum KEMs presents developers with non-trivial architectural and performance challenges. Unlike classical encryption, where the sender chooses and encrypts a symmetric key, a KEM inverts this model. The shared secret is a fresh, random value generated as an output of the encapsulation process itself, which means developers cannot simply replace a traditional Encrypt() function. Google strongly recommends adopting high-level standards like Hybrid Public Key Encryption (HPKE) (RFC 9180), which simplifies the integration of new KEMs and is available in libraries like Tink.
Furthermore, post-quantum public keys and ciphertexts are substantially larger, often with an order of magnitude difference. For instance, the recommended ML-KEM-768 key is approximately 18 times larger than a P-256 key, which requires architects to re-evaluate application performance, particularly concerning bandwidth, storage, and memory usage.
To mitigate against any undiscovered flaws in the new post-quantum algorithms, Google strongly recommends a hybrid approach that combines a classical and a PQC algorithm.
The new capabilities in Cloud KMS offer:
- ML-KEM-768 and ML-KEM-1024: Implementations of the NIST-standardized Module-Lattice-based Key-Encapsulation Mechanism (FIPS 203).
- X-Wing (Hybrid KEM): Recommended for most general-purpose applications, this KEM combines the classical X25519 algorithm with the post-quantum ML-KEM-768 for a layered defense.
Swamynathan Arunachalam, a Principal Architect at NielsIO, also noted the development:
GCP now supports post-quantum Key Encapsulation Mechanisms in Cloud KMS, in preview, enabling customers to begin migrating to a post-quantum world.
Google Cloud is making its underlying implementations available through its open-source cryptographic libraries, BoringCrypto and Tink, and plans to roll out PQC for its own infrastructure connections by 2026. The Tink library will also provide more user-friendly support for HPKE in Java, C++, Golang, and Python by the end of this year.
Lastly, despite the growing threat, organizational readiness remains low. Toyosi Kuteyi, Privacy and Compliance Specialist at Actalent, highlighted this gap in a recent blog post:
While awareness of the quantum threat is growing, readiness is low:
- Only 9% of organizations have a post-quantum roadmap (Bain & Co., 2024).
- Reports from PwC and Microsoft show most organizations are still “valuating options”.
- Many assume they’re not targets — creating a false sense of security.
This gap between awareness and action is what makes 2025 so critical.
Lastly, the company states that integrating quantum-safe KEMs into workflows is straightforward with the Cloud KMS API. Detailed instructions and code samples are available in the documentation pages.
