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

On Fri, Aug 9, 2019 at 10:54:51PM -0400, Bruce Momjian wrote:
> On Thu, Aug 8, 2019 at 10:17:53PM -0400, Sehrope Sarkuni wrote:
> > On Thu, Aug 8, 2019 at 2:16 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > On Wed, Aug  7, 2019 at 08:56:18AM -0400, Sehrope Sarkuni wrote:
> > > Simplest approach for derived keys would be to use immutable attributes
> > of the
> > > WAL files as an input to the key derivation. Something like HKDF(MDEK,
> > "WAL:" |
> >
> > So, I am thinking we should use "WAL:" for WAL and "REL:" for heap/index
> > files.
> >
> >
> > Sounds good. Any unique convention is fine. Main thing to keep in mind is that
> > they're directly tied to the master key so it's not possible to rotate them
> > without changing the master key.
>
> A recent email talked about using two different encryption keys for
> heap/index and WAL, which allows for future features, and allows for key
> rotation of the two independently. (I already stated how hard key
> rotation would be with WAL and pg_rewind.)

So, I just had an indea if we use separate encryption keys for
heap/index and for WAL --- we already know we will have an offline tool
that can rotate the passphrase or encryption keys. If we allow the
encryption keys to be rotated independently, we can create a standby,
and immediately rotate its heap/index encryption key. We can then start
streaming replication. When we promote the standby to primary, we can
then shut it down and rotate the WAL encryption key --- the new primary
would then have no shared keys with the old primary.

--
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 +