[Java] CMM cache policy on decryption DEKs

[mkeskells]

While profiling an application I could find latency spikes, relate to decryption

If an application is regularly using a DEK for decryption, it can expire due to its TTL
As I read the code the TTL is set when the key is created. Is seems sensible that the key would expire when not used, but if used frequently why should it expire?

I appreciate that its a bit harder to manage different expiration policy for encryption and decryption, and that old unused DEKs should be expired, but it seems to me that this isn't the case for frequently used decryption DEKs.
The decryption materials if deleted would be creates again moments later (I am presuming the same materials), so this seems to be an unnessessary latency

Could we either refresh in the background, or change the eviction semantics

Happy to contribute/colaborate but will need some steer for the existing maintainers

[ajewellamz]

Greetings mkeskells,

The time to live (TTL) is defined as the time from creation, not the time since last use.

The reason the TTL exists is that the source of the materials (e.g. KMS) might revoke permissions at any time. The TTL sets an upper bound on the length of time between KMS revoking permissions and the application being unable to use the materials.

This is the same for encryption and decryption.

If the TTL were refreshed each time it were used, a KMS permission revocation could take a long time to propagate.

[mkeskells]

Hi ajewellamz,

In our environment we use TTL to force rotate new encryption DEKs, and to expire decryption DEKs that are not useful to the cache (maybe thats abusing the idea... maybe we want different TTL for encryption and decryption as well)

We may have several thousand decryption DEKs in the cache, and regularly in use, and then we see a spike of a many decryption DEKs being regenerated, because they have expired due to TTL, which causes application latency (and some cost)

We have implemented a mechanism to rotate encryption DEKs as we know the limited set of keys in use. Effectively just regenerate the key 10 second before it would expire, but his path doesn't block encryption calls as it doesn't evict from the cache, it just replaces the entry when regenerated - #840

I don't particularly want to write our own cache....
Maybe we could periodically revalidate the decryption DEKs in a similar way, just before they expire. If this is in the background we dont see the latency spikes.
I am sure we are not the only users with latency sensitive applications though. It would be good to see if we can add to the library behaviours if we can find a pattern that works