Envelope Encryption and DEK caching

[sebcante]

Is your feature request related to a problem?

No

What sort of feature would you like to see?

I have a general question about using Tink and EnvelopeEncryption.

I tried the example GOLANG-HOWTO.md#envelope-encryption, it works great.

I wonder if it is possible, or if it is a roadmap feature to allow configuring reusing DEK for a set number of Encrypt() instead of creating a new DEK (and encrypted with remote KMS) for each Encrypt()

I understand the best practices is to use a new DEK for each message to encrypt. However past a certain volume, I am considering balancing cost and security. Each DEK are encrypted with remote KMS, for high volume message, the KMS cost becomes significant.

This feature would be very similar as the data key caching documented by AWS Encryption SDK DataKey Caching, ie allow configuring threshold to drive whether to re-use the DEK or not.

Have you considered any alternative solutions?

If this feature is not planned, i would really value pointers how best to customize tink to allow envelope encryption data key caching.

I am wondering if the best place to extend tink is creating a new Key Manager similar than kms_envelope_aead_key_manager.go and add some sort of cache around in a newer version of KMSEnvelopeAEAD where before we generate a new DEK we get one from a cache if the reuse threshold is acceptable.

Thanks! -seb

[juergw]

Yes I agree that this would be something that would be nice to have. But for the near future we don't have plans to add this.

[juergw]

One thing you could do is the same approach I outlined here: https://github.com/google/tink/issues/527#issuecomment-1408760976 for StreamingAead. Instead of using EnvelopeAead, you create a new Aead keyset yourself, and then encrypt it using your KMS key and store the encryption somewhere. You then use your Aead primitive for as many encryptions as you want. When you want to decrypt, you first need to decrypt the encrypted keyset using the KMS key. And then you can decyrpt as many messages as you want. This will be very flexible, but you will need to know yourself which keyset was used with which encrypted data. Would that work for you?

[juergw]

I had some discussions with other members of the team, and we agree that what I suggested above is our preferred solution. We will not add caching to KMSEnvelopeAEAD. So I'm going to close this.

[sebcante]

Thanks @juergw i ll try your suggestion using StreamingAead