Date: Tue, 13 Jun 2017 11:04:21 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Ants Aasma <ants.aasma@eesti.ee>, Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Data at rest encryption
Message-ID: <20170613150421.GE3151@tamriel.snowman.net>
References: 
 <CA+CSw_tb3bk5i7if6inZFc3yyf+9HEVNTy51QFBoeUk7UE_V=w@mail.gmail.com>
 <06b6db11-3a3f-4d24-6f57-450f96ecda84@2ndquadrant.com>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="rU/2C8Pi2woy9Lyw"
Content-Disposition: inline
In-Reply-To: <a79fc30c-848a-cf88-a2ff-0234df45f1dc@2ndquadrant.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--rU/2C8Pi2woy9Lyw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> I wonder what the proper extent of "encryption at rest" should be.  If
> you encrypt just on a file or block level, then someone looking at the
> data directory or a backup can still learn a number of things about the
> number of tables, transaction rates, various configuration settings, and
> so on.  In the scenario of a sensitive application hosted on a shared
> SAN, I don't think that is good enough.

If someone has access to the SAN, it'd be very difficult to avoid
revealing some information about transaction rates or I/O throughput.
Being able to have the configuration files encrypted would be good
(thinking particularly about pg_hba.conf/pg_ident.conf) but I don't
know that it's strictly necessary or that it would have to be done in an
initial version.

Certainly, there is a trade-off here when it comes to the information
which someone can learn about the system by looking at the number and
sizes of files from using PG-based encryption vs. what information
someone can learn from being able to look at only an encrypted
filesystem, but that's a trade-off which security experts are good at
making a determination on and will be case-by-case, based on how easy
setting up filesystem-encryption is in a particular environment and what
the use-cases are for the system.

> Also, in the use case you describe, if you use pg_basebackup to make a
> direct encrypted copy of a data directory, I think that would mean you'd
> have to keep using the same key for all copies.

That's true, but that might be acceptable and possibly even desirable in
certain cases.  On the other hand, it would certainly be a useful
feature to have a way to migrate from one key to another.  Perhaps that
would start out as an off-line tool, but maybe we'd be able to work out
a way to support having it done on-line in the future (certainly
non-trivial, but if we supported multiple keys concurrently with a
preference for which key is used to write data back out, and required
that checksums be in place to allow us to test if decrypting with a
specific key worked ... lots more hand-waving here... ).

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJZP/71AAoJEO1sijiDR2RVhdsQAMfX1cMknc03IeRpte9msSTy
k3XbutaFEC3HzfkCXVLQmY661GxAyJEVeCU10l0Nm/btT+GXwIpvohNCKDK/sWGI
rs1G4y3ikWf4VIVZgN0G3eO5mwePHdRsyt9h2XQHc3xma0uae8GnI57mmxOeXtlJ
msK2VVloMvX5NDsvrB0hVHWrqFL2aDgW0iGsj8kKJkjJd8yqh0KR1S3NjY7hesns
18oJuEXt96nfzzgAHMBH09hzqs0Dd8HHpqaUyE134LMn2YTcfUPWkXsZzB1/mU4e
8OE6Y4e/TY55zdYXCWvP0wknJixP6o42prcVDGLsYR0wmWDwtj2y2ZWOUzHaCYDc
fexulu5pBLH0cUhV30iEa298m5LK1Zs+u1vvL3u5T9Jg9GzQ+zbeMYE9VaYllzqN
lsvy4EHda7OYGRQHxNoctOqpfXVFlTtle6jjRz+ptF85gjpSkFLkgZ+VbStmVNam
6ArqX2bEg7ah2mdGTs0xweM8d3VJWgO857GurHwVq1+Vr5EDxh2SVU2Uop9rHrLg
gtmd5bRmjrYafrEzexPph37OYMLhEjvybB+aR3FRgf71YC8LZBNlWre+DZhcl7tP
60Tzq8EHlHQf64fatQPNnmst8eroLVD+VCVg41sLOlUu9VYkumIfKfEKJXd6KmLp
fmhVnRb9zhxhWRBhm1jT
=O1WW
-----END PGP SIGNATURE-----

--rU/2C8Pi2woy9Lyw--