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: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Tomas Vondra <tomas.vondra@2ndquadrant.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-08-06T22:45:06Z
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 Tue, Aug  6, 2019 at 06:13:30PM -0400, Jonathan Katz wrote:
> Hi,
> 
> On 8/6/19 3:01 PM, Bruce Momjian wrote:
> > On Tue, Aug  6, 2019 at 01:55:38PM -0400, Bruce Momjian wrote:
> >> CTR mode creates a bit stream for the first 16 bytes with nonce of
> >> (segment_number, counter = 0), and the next 16 bytes with 
> >> (segment_number, counter = 1), etc.  We only XOR using the parts of the
> >> bit stream we want to use.  We don't care what the WAL content is --- we
> >> just XOR it with the stream with the matching counter for that part of
> >> the WAL.
> > 
> > The diagram which is part of this section might be helpful:
> > 
> > 	https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)
> > 	https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#/media/File:CTR_encryption_2.svg
> 
> This is going to be a slightly long (understatement) email that I
> thought would be easier to try to communicate all in one place vs.
> replying to individual parts on this long thread. My main goal was to
> present some things I had researched on TDE, some of which had been
> mentioned on thread, and compile it in one place (it's also why I was
> slow to respond on some other things on the thread -- sorry!)

This basically tries to re-litigate many discussions we have already
had, and I don't see much value in replying point by point.  It
relitigates:

*  table/tablespace-level encryption keys (single WAL file and unlocked
keys for recovery)

*  CTR mode

*  Authentication of data (we decided we would not do this for v1 of
this feature)

* Use of something like "ssl_passphrase"

If you want to relitigate something, you will need to state that, and
reference the previous arguments in explaining your disagreement.

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