Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 2019-Jul-15, Bruce Momjian wrote:

> My point is that doing encryption of only some data might actually make
> the system slower due to the lookups, so I think we need to implement
> all-cluster encryption and then see what the overhead is, and if there
> are use-cases for not encrypting only some data.

We can keep the keys in the relcache. It doesn't have to be slow. It
is certainly slower to have to encrypt *all* data, which can be
massively larger than the sensitive portion of the database.

If we need the keys for offline operation (where relcache is not
reachable), we can keep pointers to the key files in the filesystem --
for example for an encrypted table we would keep a new file, say
<relfilenode>.key, which could be a symlink to the encrypted key file.
The tool already has access to the key data, but the symlink lets it
know *which* key to use; random onlookers cannot get the key data
because the file is encrypted with the master key.

Any table without the key file is assumed to be unencrypted.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services