Re: Transparent column encryption - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Transparent column encryption
Date
Msg-id ad1eab7d-04da-95ee-9377-7b1fd312f905@enterprisedb.com
Whole thread Raw
In response to Re: Transparent column encryption  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 10.01.23 18:26, Mark Dilger wrote:
> I wonder if logical replication could be made to work more easily with this feature.  Specifically, subscribers of
encryptedcolumns will need the encrypted column encryption key (CEK) and the name of the column master key (CMD) as
existson the publisher, but getting access to that is not automated as far as I can see. It doesn't come through
automaticallyas part of a subscription, and publisher's can't publish the pg_catalog tables where the keys are kept
(becausepublishing system tables is not supported.)  Is it reasonable to make available the CEK and CMK to subscribers
inan automated fashion, to facilitate setting up logical replication with less manual distribution of key information?
Isthis already done, and I'm just not recognizing that you've done it?
 

This would be done as part of DDL replication.

> Can we do anything about the attack vector wherein a malicious DBA simply copies the encrypted datum from one row to
another?

We discussed this earlier [0].  This patch is not that feature.  We 
could get there eventually, but it would appear to be an immense amount 
of additional work.  We have to start somewhere.


[0]: 
https://www.postgresql.org/message-id/4fbcf5540633699fc3d81ffb59cb0ac884673a7c.camel@vmware.com




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: split TOAST support out of postgres.h
Next
From: Peter Eisentraut
Date:
Subject: Re: drop postmaster symlink