From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Jacob Champion <jchampion(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transparent column encryption |
Date: | 2022-07-21 19:29:00 |
Message-ID: | Ytmo/Pq9UyzaMaQy@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 18, 2022 at 12:53:23PM +0200, Peter Eisentraut wrote:
> Asymmetric keys gives you some more options for how you set up the keys at
> the beginning. For example, you create the asymmetric key pair on the host
> where your client program that wants access to the encrypted data will run.
> You put the private key in an appropriate location for run time. You send
> the public key to another host. On that other host, you create the CEK,
> encrypt it with the CMK, and then upload it into the server (CREATE COLUMN
> ENCRYPTION KEY). Then you can wipe that second host. That way, you can be
> even more sure that the unencrypted CEK isn't left anywhere. I'm not sure
> whether this method is very useful in practice, but it's interesting.
>
> In any case, as I mentioned above, this particular aspect is up for
> discussion.
I caution against adding complexity without a good reason, because
historically complexity often leads to exploits and bugs, especially
with crypto.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-07-21 20:00:17 | Re: make -C libpq check fails obscurely if tap tests are disabled |
Previous Message | Dean Rasheed | 2022-07-21 18:36:38 | Re: Make name optional in CREATE STATISTICS |