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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date: 2019-08-15 12:25:07
Message-ID: 20190815122507.GB25063@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 14, 2019 at 09:19:44PM -0400, Bruce Momjian wrote:
> I think there are several directions we can go after all-cluster
> encryption, and it does matter because we would want minimal API
> breakage. The options are:
>
> 1) Allow per-table encyption control to limit encryption overhead,
> though all of WAL still needs to be encrypted; we could add a
> per-record encyption flag to WAL records to avoid that.
>
> 2) Allow user-controlled keys, which are always unlocked, and encrypt
> WAL with one key
>
> 3) Encrypt only the user-data portion of pages with user-controlled
> keys. FREEZE and crash recovery work since only the user data is
> encrypted. WAL is not encrypted, except for the user-data portion
>
...
> I don't think #3 is viable since there is too much information leakage,
> particularly for indexes because the tid is visible.

Thinking some more, it might be possible to encrypt the index tid and
for crash recovery and the freeze part of vacuum to work, which might be
sufficient to allow the user keys to remain locked.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-08-15 13:48:00 Re: Don't like getObjectDescription results for pg_amop/pg_amproc
Previous Message Peter Eisentraut 2019-08-15 11:37:12 Allow cluster owner to bypass authentication