Horton

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

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Sehrope Sarkuni <sehrope@jackdb.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-29T23:43:05Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

On Mon, Jul 29, 2019 at 05:53:40PM -0400, Sehrope Sarkuni wrote:
> I don't think this will be an issue in practice, but it should be documented.
> Otherwise, it's not unreasonable for someone to expect that a promoted replica
> would use be using new keys for everything after each promotion.
> 
> Encryption for WAL can avoid this type of problem entirely by generating a new
> random salt and adding a "Use new salt XYZ for WDEK going forward" record. The
> two replicas would generate different salts so all subsequent encrypted WAL
> data would be different (even the exact same records). Unfortunately, that
> doesn't work for pages without a lot more complexity to keep track of which key
> version to use based upon the LSN.

Oh, yeah, WAL is the big issue here, not the heap/index files, since we
know they will use the same segment number in both clusters.  We can't
use the timeline in the WAL IV since they will both be on the same
timeline.  Anyway, I think the heap/index is still an issue so we should
just document "don't do that".

-- 
  Bruce Momjian  <bruce@momjian.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 +