Problem:
While profiling an application we noticed duplicate request for encryption keys and decryption keys, typically after an DEK has just expired
Solution:
The cause of this was on a miss used by expiration of an encryption DEK or a decryption DEK. In our case both were related to TTL
for a simple example - imaging 10 threads encrypting data, using the same keys. The key expires, and 10 threads, make 10 request to the MasterKey for 10 new encryption DEKs, which causes a little more latency, and cost (if the underlying KMS charges)
I think that the library can easily de-duplicate these requests (maybe as an option). We have done this in our application
Happy to contribute/colaborate on this but will need some steer from the maintainers
Out of scope:
Is there anything the solution will intentionally NOT address?
Problem:
While profiling an application we noticed duplicate request for encryption keys and decryption keys, typically after an DEK has just expired
Solution:
The cause of this was on a miss used by expiration of an encryption DEK or a decryption DEK. In our case both were related to TTL
for a simple example - imaging 10 threads encrypting data, using the same keys. The key expires, and 10 threads, make 10 request to the MasterKey for 10 new encryption DEKs, which causes a little more latency, and cost (if the underlying KMS charges)
I think that the library can easily de-duplicate these requests (maybe as an option). We have done this in our application
Happy to contribute/colaborate on this but will need some steer from the maintainers
Out of scope:
Is there anything the solution will intentionally NOT address?