On Sat, Mar 2, 2019 at 6:23 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Mar 1, 2019 at 3:52 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
> > The Cybertec proposed patches are doing the encryption at the instance
> > level, AFAIK, the current discussion is also trying to reduce the scope of the
> > encryption to object level like (tablesapce, database or table) to avoid the encryption
> > performance impact for the databases, tables that don't need it.
>
> The trick there is that it becomes difficult to figure out which keys
> to use for certain things. For example, you could say, well, this WAL
> record is for a table that is encrypted with key 123, so let's use key
> 123 to encrypt the WAL record also. So far, so good. But then how do
> you encrypt, say, a logical decoding spill file? That could have data
> in it mixed together from multiple relations, IIUC.
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.
> 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?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
