Date: Tue, 13 Jun 2017 14:06:24 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Joe Conway <mail@joeconway.com>, Robert Haas <robertmhaas@gmail.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Ants Aasma <ants.aasma@eesti.ee>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Data at rest encryption
Message-ID: <20170613180624.GO3151@tamriel.snowman.net>
References: <20170613162301.GF3151@tamriel.snowman.net>
 <CA+TgmoYeEigW3ERT5AKUc-QWBOSuS5ZDFJDRJm1=hDv2Q=0zLw@mail.gmail.com>
 <26430417-5b4b-b647-9a23-3da213714ffe@joeconway.com>
 <20170613165836.GE13873@momjian.us>
 <20170613170522.GI3151@tamriel.snowman.net>
 <8f540898-d703-7d83-3f61-f6b58a74a3e6@joeconway.com>
 <20170613172030.GK3151@tamriel.snowman.net>
 <efb190e5-6407-0c5c-6330-46b0995c6509@joeconway.com>
 <20170613174451.GN3151@tamriel.snowman.net>
 <20170613174818.GM13873@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="o1zMaoGn08M3Na1d"
Content-Disposition: inline
In-Reply-To: <20170613174818.GM13873@momjian.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--o1zMaoGn08M3Na1d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Bruce,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jun 13, 2017 at 01:44:51PM -0400, Stephen Frost wrote:
> > Just to be clear, I don't have any issue with discussing the idea that
> > we want to get to a point where we can work with multiple keys and
> > encrypt different tables with different keys (or not encrypt certain
> > tables, et al) with the goal of implementing the single-key approach in
> > a way that allows us to expand on it down the road easily, I just don't
> > think we need to have it all done in the very first patch which adds the
> > ability to encrypt the data files.  Maybe you're not saying that it has
> > to be included in the first implementation, in which case we seem to
> > just be talking past each other, but that isn't the impression I got..
>=20
> We don't want to implement all-cluster encryption with a simple user API
> and then realize we need another API for later encryption features, do
> we?

I actually suspect that's exactly where we'll end up- but due to
necessity rather than because there's a way to avoid it.  We are going
to want to encrypt cluster-wide components of the system (shared
catalogs, WAL, etc) and that means that we have to have a key provided
very early on.  That's a very different thing from being able to do
something like encrypt specific tables, tablespaces, etc, where the key
can be provided much later and we'll want to allow users to use SQL or
the libpq protocol to be able to specify what to encrypt and possibly
even provide the encryption keys.

That said, the approach outlined here could be used for both by
expanding on the command string, perhaps passing it a keyid which is
what we store in the catalog to indicate what key a table is encrypted
with and then the keyid is "%k" in the command string and the command
has to return the specified key for us to decrypt the table.  That would
involve adding a new catalog table to identify keys and their keyids,
I'd think, and an additional column in pg_class which specifies the key
(or perhaps we'd just have a new catalog table that says what tables are
encrypted in what way).

Thanks!

Stephen

--o1zMaoGn08M3Na1d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJZQCmgAAoJEO1sijiDR2RVsHsP/i8UjgPjolzKrh0E2OELY9xx
AMNqUwY3hIRhinA8C+9BJIhLwj/ppZ3qKFGZlZj5mTIPugvNg2PacQCGPbwbkhw3
TpH+BJH5ux1nF/tL7Bqy4aatbJjjRi3CTa6JAs6GQebv/KI6SEbzBBhbRdXM0q03
RUYzE3Y5PPSUMw8TyAgSF/LY0kUKPausG6qixvK0Aytf9A6ChaSrAsff6blAGaKz
IGs0R5Tg4USPaRTLqcGY4Me29kFHA7MAHTEpxZl8WsiI8F/9AtWvSXUTEQnBTrBK
wNYVZJpAaew8n1GBtEMusNQuZieJ4FiMqKx4tVvOIHs1cNMAI6cHHiJ94MX+Yduv
AlVr+kOOs6yoBF7hnL2Tmfy1dhmw6anCLCB8zSLvjMdd4hNjcKoipfCTAAPwA4w1
S2DNFP9nqHLxEV784Woy36omdyAQ+lTJSoB6/KpC6LM3ZjTZ3a/zknHZxXPbDcyA
83OjBCNSW1kVGjfBeMnmg8rCs1H69UAry8X6m+yXwur6omGmcV6mMA8FPvD1kmyQ
smG3EMPlcsTklZe/O2gJGoNz7Guz3Kh8QwzwmstaVGsAxOdEFnD34TMFafv7Fx8N
3E4vV1Tx6irAUWqs2hqWYLejrBe2hMbvej3enqhxMQC7UjncDrZ+DpDTOvpQsEKr
vaFrrqsXD1rJ25KER0Eh
=2FXV
-----END PGP SIGNATURE-----

--o1zMaoGn08M3Na1d--