Google's Key Management System: data unencryption after key rotation

Question

Context

I am following GCP's instructions for Storing Secrets in Storage Bucket. KMS is used for file encryption before it's being uploaded to Storage Bucket.

Since data encryption happens outside of Google's storage I am a bit confused with one aspect of key rotation.

Scenario

Let's consider a specific scenario:

1. On 2017-01-01 I create a keyring and a key A (which is in fact A_ver1 because the keys are versioned). Also, the key rotation policy is set up to trigger rotation yearly.
2. On 2017-01-15 I run a command to encrypt some_file.txt with A_ver1: curl -s -X POST "https://cloudkms.googleapis.com/v1/projects/my-project/<...>" \ -d "{\"plaintext\":\"<...SOME_FILE_CONTENT...>\"}" \ -H "Authorization:Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type:application/json".
3. I immediately save the result of encryption to Storage Bucket as some_file.txt.encrypted.
4. I don't do anything, and on 2018-01-01 the key rotation happens. As I understand, A_ver1 gets disabled, A_ver2 is generated and activated. These two events happen quasi-simulataneously.
5. On 2018-06-01 I realize that I need to unencrypt some_file.txt.encrypted. I am downloading the file, then trying to run a command to unencrypt the file using the A_ver2...

Questions

Question 1: What is going to happen when I try to unencrypt the file with A_ver2 if it was encrypted with the earlier version A_ver1?

Question 2: If the unencryption fails, what am I supposed to do in the first place to prevent it?

Answer 1

In your scenario, the description of rotation in step 4 is not quite right. When you rotate a CryptoKey, a new CryptoKeyVersion is generated and made the primary version of the CryptoKey, but nothing happens to the old version. That is, for your scenario, A_ver1 is still enabled, but another enabled version A_ver2 is the primary version.

To answer your questions,

Question 1: When you try to decrypt a file, you do not need to specify the CryptoKeyVersion, only the CryptoKey; the service will get the right version for you. If you try to decrypt a file that has been encrypted with a CryptoKeyVersion that is now disabled (or destroyed), then the decrypt call will fail.

Question 2: It depends what you're optimizing for. If you are using rotation to try to limit the amount of data encrypted with any one version, for example, then you may not want to disable old versions, and keep these for a prolonged period of time. You may only want to disable key versions beyond some large number of versions. In that case, you could track which key version you used for a particular piece of data, and re-encrypt all affected data.

Answer 2

Old versions are not automatically disabled on rotation.

Question 1: When you decrypt with a particular CryptoKey, the server chooses the correct version (mentioned in the Decrypt document). As long as a version is not disabled, it is still usable.

Question 2: In your particular scenario, decryption won't fail due to using the old version.

Key rotation mentioned the behavior you expect, and as it notes implementing a strategy that re-encrypts data with new versions and disables the old ones can be tricky.

Please let me know if you have any other questions.