As enterprises increasingly adopt multicloud architectures, bring your own key (BYOK) has become a fundamental pillar for maintaining data sovereignty and helping protect critical cloud workloads. At the same time, quantum computing has rapidly advanced, and security teams need to re-evaluate how they securely transfer encryption keys across networks.

Following our previous announcements of quantum-safe digital signatures and quantum-safe key encapsulation mechanisms (KEMs) in Cloud Key Management Service (Cloud KMS), we are excited to announce the preview of quantum-safe key import in Cloud KMS for software-based cryptographic keys.

Our updated quantum-safe BYOK capability, the first step of the next phase of our post-quantum cryptography (PQC) migration timeline, can help you protect your sensitive keys before a cryptographically-relevant quantum computer (CRQC) emerges.

As you adopt quantum-safe key import to help protect your keys in transit, you can also monitor your overall post-quantum posture with Cloud KMS PQC insights, now generally available. This high-level visual illustrates your asymmetric keys based on the categorization of the algorithms they use, and can help you plan for future modernization and support long-term resilience.

The threat: Store Now, Decrypt Later attacks

Traditional key import methods rely on classical asymmetric encryption standards to wrap keys during transit. While these algorithms successfully defend against today’s threats, they will become fundamentally insecure when a viable quantum computer emerges that can potentially decrypt keys that adversaries have intercepted and stored. 

Quantum-safe key import helps mitigate these store now, decrypt later (SNDL) attacks by wrapping your keys in a quantum-resistant envelope from day one.

Building a quantum-resistant envelope for keys

The post-quantum transit mechanism now available in Cloud KMS uses hybrid public key encryption (HPKE). Our new import method wraps your sensitive software key material in a quantum-resistant transit envelope. The process integrates into the existing Cloud KMS API workflow to minimize your work:

• Initiating the job: The client creates a new import job through the Cloud KMS API, requesting a post-quantum HPKE import method.

• Key generation: The Cloud KMS server generates a post-quantum KEM private key and exposes the corresponding public key to the client.

• Client-side wrapping: Using a supported cryptographic library (such as Tink or OpenSSL), the client executes an HPKE Seal() operation. This encapsulates the public key to establish a shared secret, derives an ephemeral AES key using HKDF-SHA256, and encrypts the target key material.

• Submission: The client transmits the encapsulated ciphertext concatenated directly with the encrypted key material back to the Cloud KMS endpoint, which already has quantum-safe data-in-transit protection built-in.

• Unwrapping: The Cloud KMS server executes an HPKE Open() operation using its private portion of the wrapping key to safely decrypt and help protect the key material within the Cloud KMS boundary.

For the KEM layer, you can choose between X-Wing, ML-KEM-768, or ML-KEM-1024. The key derivation layer utilizes HKDF-SHA-256, and the final symmetric wrapper employs AES-256-GCM with standard 12-byte nonces.

To learn more about setting up your import jobs, preparing your local key material using external cryptographic libraries, and managing quantum-safe solutions, check out our Cloud KMS quantum safe key import documentation.

A critical milestone in Google Cloud's PQC journey

The global migration to post-quantum cryptography is a marathon that you take one milestone at a time. Today, you can create your first quantum safe key import job and begin the process of helping make your applications quantum-safe. 

We welcome your feedback and invite you to reach out to explore how we can support your organization's post-quantum strategy.