RE: Application Level Encryption

From: Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
Sent: 05 July 2020 23:32
To: Sam Gendler <sgendler(at)ideasculptor(dot)com>
Cc: Zahir Lalani <ZahirLalani(at)oliver(dot)agency>; pgsql-general(at)postgresql(dot)org
Subject: Re: Application Level Encryption

On Sun, Jul 5, 2020 at 3:23 PM Sam Gendler <sgendler(at)ideasculptor(dot)com<mailto:sgendler(at)ideasculptor(dot)com>> wrote:

On Sun, Jul 5, 2020 at 11:41 AM Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com<mailto:pelletier(dot)michel(at)gmail(dot)com>> wrote:

I'm working on an approach where the decrypted DEK only lives for the lifetime of a transaction, this means hitting the kms on every transaction that uses keys. It will be slower, but the time the decrypted key stays in memory would be minimized.

Watch out for KMS api quotas if you go that route. Their docs don't state what the default quotas are, so you have to go to your quotas page in the console to find out, but they likely aren't very high and might well be exceeded by the transaction rate on even a relatively small db instance.

Thanks for pointing that out, it's true that it's a limited route with cloud KMS. If you control the device like a Zymkey in a secure enclosure, the cost is minimal, although the key derivation rate is very slow.

-Michel

**
Thank you for the explanation – that makes sense, but I need to read the docs to understand better. Any suggestions on how people usually deal with reporting in this scenario, considering off the shelf tools don’t usually have this mechanism?

Z