googleapis / python-kms

This library has moved to https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-kms
Apache License 2.0
33 stars 32 forks source link

No way to verify symmetric encryption/decryption? #22

Closed mflaxman closed 4 years ago

mflaxman commented 4 years ago

Is your feature request related to a problem? Please describe. I want to load my own keys into Google Cloud and then use your service for symmetric encryption/decryption of plaintext that I provide. This is fairly straightforward, but I don't see anywhere to verify that it's actually working. The whole point of loading my own keys in (as opposed to having google generate them) is that I can keep a copy of these keys and know that no matter what I can use these keys in the future to decrypt my ciphertext. With the current setup, I'm forced to rely on google to decrypt my ciphertext in the future.

Describe the solution you'd like I'd like a file like python-kms/samples/attestations/verify_attestation.py but for verifying a symmetric key. It would do the same thing as the decrypt_symmetric method in python-kms/samples/snippets/decrypt_symmetric.py but I could run it without a network connection (provided I supply both ciphertext and the private key).

Describe alternatives you've considered My use-case requires no vendor lock-in, so I would be forced to use a competitor's product :(

Additional context I'd love to see more details about your symmetric encryption. For example, what algorithm is used and where do the parameters come from? If I re-encrypt the same file twice I get different cyphertext, so this indicates to me that some sort of initialization vector is being generated (randomly?).

Here I've used the command line, but I could've done this equally in python:

$ echo sssh > secret.txt
$ gcloud kms encrypt --key generated_key --keyring test_key_ring --location global --plaintext-file secret.txt --ciphertext-file secret.enc
$ gcloud kms encrypt --key generated_key --keyring test_key_ring --location global --plaintext-file secret.txt --ciphertext-file secret2.enc
$ shasum -a 256 *.enc
3368f2654cb610e03049aee9712fada530a7b7a1bfa6565ca8448eb66435686e  secret.enc
0cd09c297448b8feb250ef04f6af4198f8ba3bb118928f3bf53e22534efc418c  secret2.enc

I've encrypted the same file (secret.txt) twice and you can see the ciphertext returned is different each time.

busunkim96 commented 4 years ago

@sethvargo Could you take a look?

Labeled tentatively as a feature request, but it looks like this could be a request for a new sample.

sethvargo commented 4 years ago

You can import keys into Google Cloud KMS using Key Import: https://cloud.google.com/kms/docs/importing-a-key

The ciphertext varies because, like most key management systems, Cloud KMS does not use Homomorphic Encryption.

mflaxman commented 4 years ago

Thanks for the quick response @sethvargo!

Importing keys works great, but that's only part of what I'm trying to do:

  1. Generate keys locally on hardware I control.
  2. Import keys into google could KMS.
  3. Encrypt plaintext using KMS. glcoud returns me ciphertext that I store in my database.
  4. Decrypt ciphertext stored in my database with keys (that I have a local copy of) without hitting google's servers.

Steps 1-3 are pretty straightforward, but step 4 seems not supported?

If I can't do step 4, then there's no point in step 1 (I might as well just have google generate the keys if I can't do anything on my own with them). Does that make sense?

I'd really like to use google cloud if local decryption/verification is supported, but this project requires no vendor lock-in :(

Thanks.

sethvargo commented 4 years ago

It sounds like asymmetric encryption might be a better fit for your use case then: https://cloud.google.com/kms/docs/encrypt-decrypt-rsa

As far as I know, no major cloud providers or popular tools offer fully homomorphic encryption and portable ciphertext. It'd be helpful to learn more about your specific use case and requirements for the problem you're trying to solve.

busunkim96 commented 4 years ago

Closing as this seems to be resolved.