On Wed, Aug 14, 2019 at 09:19:44PM -0400, Bruce Momjian wrote:
> I think there are several directions we can go after all-cluster
> encryption, and it does matter because we would want minimal API
> breakage. The options are:
>
> 1) Allow per-table encyption control to limit encryption overhead,
> though all of WAL still needs to be encrypted; we could add a
> per-record encyption flag to WAL records to avoid that.
>
> 2) Allow user-controlled keys, which are always unlocked, and encrypt
> WAL with one key
>
> 3) Encrypt only the user-data portion of pages with user-controlled
> keys. FREEZE and crash recovery work since only the user data is
> encrypted. WAL is not encrypted, except for the user-data portion
>
...
> I don't think #3 is viable since there is too much information leakage,
> particularly for indexes because the tid is visible.
Thinking some more, it might be possible to encrypt the index tid and
for crash recovery and the freeze part of vacuum to work, which might be
sufficient to allow the user keys to remain locked.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +