On Mon, Mar 4, 2019 at 1:01 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> I think that there is no need to use the same key for both the spill
> files and WAL because only one process encrypt/decrypt spill files. We
> can use something like temporary key for that use case, which is used
> by only one process and lives during process lifetime (or transaction
> lifetime). The same is true for for other temporary files such as
> tuplesort and tuplestore, although maybe we need tricks for shared
> tuplestore.
Agreed. For a shared tuplestore you need a key that is shared between
the processes involved, but it doesn't need to be the same as any
other key. For anything that is accessed by only a single process,
that process can just generate any old key and, as long as it's
secure, it's fine.
For the WAL, you could potentially create a new WAL record type that
is basically an encrypted wrapper around another WAL record. So if
table X is encrypted with key K1, then all of the WAL records for
table X are wrapped inside of an encrypted-record WAL record that is
encrypted with key K1. That's useful for people who want fine-grained
encryption only of certain data.
But for people who want to just encrypt everything, you need to
encrypt the entire WAL stream, all SLRU data, etc. and that pretty
much all has to be one key (or sub-keys derived from that one key
somehow).
> > Or what do you do
> > about SLRUs or other global structures? If you just exclude that
> > stuff from the scope of encryption, then you aren't helping the people
> > who want to Just Encrypt Everything.
>
> Why do people want to just encrypt everything? For satisfying some
> security compliance?
Yeah, I think so. Perhaps an encrypted filesystem is a better way to
go, but some people want something that is built into the database
server. The motivation seems to be mostly that they have a compliance
requirement -- either the database itself encrypts everything, or they
cannot use the software.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
