On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
IMHO we should implement the simplest system possible, and optimize the
hell out of it without sacrificing any safety/security aspects. No smart
tunables, no extra GUCs to trade security for performance, nothing.
Then once we have this working, we can see what the impact is, and make
informed choices based on that. It's really hard to make good choices
based on speculation, which is all we have at this point. And the danger
is we'll end up with overly complex system with many parameters - which
is pretty bad when the configuration impacts security, because regular
users may not reaslise the consequences (and we'll get blamed for it).
Also, in my experience the deployments that really need this sort of
encryption tend to be quite valuable, and the owners will be happy with
higher hardware costs to compensate for the performance impact, if it
gives them the feature. So even if the performance impact is 20% (worst
case estimate), I'd say that may be acceptable.
Totally agree.
I personally find the idea of encrypting tablespaces rather strange.
Tablespaces are meant to define hysical location for objects, but this
would also use them to "mark" objects as encrypted or not. That just
seems misguided and would make the life harder for many users.
For example, what if I don't have any tablespaces (except for the
default one), but I want to encrypt only some objects? Suddenly I have
to create a tablespace, which will however cause various difficulties
down the road (during pg_basebackup, etc.).
Yes, very good point.
> In addition, while the 8k blocks would use a block cipher, the WAL would
> likely use a stream cipher, and it will be very hard to use multiple
> stream ciphers in a single WAL file.
>
Umm, why? Why would WAL necessarily use stream cipher instead of a block
cipher with a suitable mode (say, CBC or XTS)? And even if it did use
some stream cipter, why would it be hard to use multiple ciphers?
Well, the value of stream ciphers is that you can write as many bytes as
you want, rather than requiring all writes to be a multiple of the block
size. The idea of having multiple tablespaces with different keys, and
switching streaming ciphers while encrypting only the part of the WAL
that needs it, and leaving the relfilenode unencrypted so we know which
keys to use, seems very complex.
OK, that makes sense.
FWIW my assumption was that we could just add an "encrypted" flag into
the main XLogRecord header, and then an extra part with important
encryption-related data - the key, and the important metadata needed by
external tools (e.g. relfilenode/block, needed by pg_waldump).
Then we wouldn't need to reshuffle the WAL, I think.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
