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

From Antonin Houska
Subject Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date
Msg-id 17775.1563194322@localhost
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> wrote:

> On Mon, Jun 17, 2019 at 11:02 PM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
> >
> > On Mon, Jun 17, 2019 at 08:39:27AM -0400, Joe Conway wrote:
> > >On 6/17/19 8:29 AM, Masahiko Sawada wrote:
> > >> From perspective of  cryptographic, I think the fine grained TDE would
> > >> be better solution. Therefore if we eventually want the fine grained
> > >> TDE I wonder if it might be better to develop the table/tablespace TDE
> > >> first while keeping it simple as much as possible in v1, and then we
> > >> can provide the functionality to encrypt other data in database
> > >> cluster to satisfy the encrypting-everything requirement. I guess that
> > >> it's easier to incrementally add encryption target objects rather than
> > >> making it fine grained while not changing encryption target objects.
> > >>
> > >> FWIW I'm writing a draft patch of per tablespace TDE and will submit
> > >> it in this month. We can more discuss the complexity of the proposed
> > >> TDE using it.
> > >
> > >+1
> > >
> > >Looking forward to it.
> > >
> >
> > Yep. In particular, I'm interested in those aspects:
> >
> 
> Attached the draft version patch sets of per tablespace transparent
> data at rest encryption.

I was worried that there's competition between us but now that I've checked
your patch set I see that you already use some parts of

https://commitfest.postgresql.org/23/2104/

although not the latest version. I'm supposed to work on the encryption now,
so thinking what to do next. I think we should coordinate the effort, possibly
off-list. The earlier we have a single patch set the more efficient the work
should be.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [proposal] de-TOAST'ing using a iterator
Next
From: Luis Carril
Date:
Subject: Re: Option to dump foreign data in pg_dump