Re: Transparent column encryption

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

In response to

Browse pgsql-hackers by date

  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