Date: Tue, 13 Jun 2017 13:05:22 -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: <20170613170522.GI3151@tamriel.snowman.net>
References: 
 <CA+TgmoaXGx=7VEVz7eq9T=raZRHm3iNc244Sx=T1UxX-+szOUQ@mail.gmail.com>
 <CA+CSw_uO6wGv2YF-RQvVOGeezJXWY+SGTKYomOY=fDNp6OmHqA@mail.gmail.com>
 <20170613132416.GD3151@tamriel.snowman.net>
 <a79fc30c-848a-cf88-a2ff-0234df45f1dc@2ndquadrant.com>
 <20170613150421.GE3151@tamriel.snowman.net>
 <20170613160434.GC13873@momjian.us>
 <20170613162301.GF3151@tamriel.snowman.net>
 <CA+TgmoYeEigW3ERT5AKUc-QWBOSuS5ZDFJDRJm1=hDv2Q=0zLw@mail.gmail.com>
 <26430417-5b4b-b647-9a23-3da213714ffe@joeconway.com>
 <20170613165836.GE13873@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vok5Yrw/eRelPH/X"
Content-Disposition: inline
In-Reply-To: <20170613165836.GE13873@momjian.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

Bruce, Joe,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote:
> > > That way, if the user wants to store the key in an unencrypted text
> > > file, they can set the encryption_key_command =3D 'cat /not/very/secu=
re'
> > > and call it a day.  If they want to prompt the user on the console or
> > > request the key from an HSM or get it in any other way, they just have
> > > to write the appropriate shell script.  We just provide mechanism, not
> > > policy, and the user can adopt any policy they like, from an extremely
> > > insecure policy to one suitable for Fort Knox.
> >=20
> > Agreed, but as Bruce alluded to, we want this to be a master key, which
> > is in turn used to encrypt the actual key, or keys, that are used to
> > encrypt the data. The actual data encryption keys could be very long
> > randomly generated binary, and there could be more than one of them
> > (e.g. one per tablespace) in a file which is encrypted with the master
> > key. This is more secure and allows, for example the master key to be
> > changed without having to decrypt/re-encrypt the entire database.
>=20
> Yes, thank you.  Also, you can make multiple RSA-encrypted copies of the
> symetric key, one for each role you want to view the data.  And good
> point on the ability to change the RSA key/password without having to
> reencrypt the data.

There's nothing in this proposal that prevents the user from using a
very long randomly generated binary key.  We aren't talking about
prompting the user for a password unless that's what they decide the
shell script should do, unless the user decides to do that and if they
do then that's their choice.

Let us, please, stop stressing over the right way to do key management
as part of this discussion about providing encryption.  The two are
different things and we do not need to solve both at once.

Further, yes, we will definitely want to get to a point where we can
encrypt subsets of the system in different ways, but that doesn't have
to be done in the first implementation either.

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJZQBtRAAoJEO1sijiDR2RVHMQQALf1oQqsZTQFqARhROJasSEf
BgnE7581v9P7SzvbTfpLMsHumKnJr0lh4ke/vcyDZDSMQBVpeixrbvI10czf1PuX
Gt3kvCBqubyQfr9pAg/krfuaW9fbARqugT83nLTi0YFjwyPQRbADdfrfqWfx7X9V
hG6W2AfdPJG/WxLrNdikDOIv4H0+xcTGSbMC4FBc8LhnlZ+pEc3SI4jP2MF+Jd4V
Xcv+tMdHFuMgXDKHjFWv48OEpE66k8zS15IdlFG66+6KejsrS3gloEOSuqFrvEtj
aSDYwngXx9E5k8BL7tSZHfiGoheXWEkqB0AKrKCxPiPITNcUozYXyWB2C0wwj8kO
katMCDywoEds0AOrdzPHb37jzYHEc3qBKRRco49f4ZareLkFWDSr3peEPPE5inTJ
z97Sn7GPhnnyY/Y8YelV0kwNI1zLxNhP83klqv3ARZ9HEsGlnpBzdAkVQu9wNo7Z
PrvaAw+xoIxKIilL0slGngT5MKyGy4z0ioH8F3kJIzEKm/2U5hfG2wieIJAeYkG+
SycomNIdav5wa7JQuRv1HsayTLSjVOIVvQVfU8JAlcvoHUZh6LK/248iOqm5Nvxr
pWdaTjb2AeZAeZhNSil/q2cS/GNORHzLdvaOleKQO8k1Itu/D/WTlLLowUOT6G8j
4gCwMfWZdfUnCeoQEM6w
=NqnU
-----END PGP SIGNATURE-----

--vok5Yrw/eRelPH/X--