Re: Application Level Encryption

From: Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
To: Sam Gendler <sgendler(at)ideasculptor(dot)com>
Cc: Zahir Lalani <ZahirLalani(at)oliver(dot)agency>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Application Level Encryption
Date: 2020-07-05 22:32:00
Message-ID: CACxu=vKTzXPf=6TK5_LZu1OkhYj1_oMtdKYgFLJ5kKBozKoxbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

>
>
> On Sun, Jul 5, 2020 at 11:41 AM Michel Pelletier <
> 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

>
>
>>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Zahir Lalani 2020-07-05 22:42:08 RE: Application Level Encryption
Previous Message Sam Gendler 2020-07-05 22:23:01 Re: Application Level Encryption