On Mon, Mar 4, 2019 at 1:01 AM Masahiko Sawada <sawada.m...@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