Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni <sehrope(at)jackdb(dot)com> wrote:
>
> On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>> > Checking that all buffers using a single LSN are from the same
>> > relation would be a good idea but I think it's hard to test it and
>> > regard the test result as okay. Even if we passed 'make checkworld',
>> > it might still be possible to happen. And even assertion failures
>>
>> Yes, the problem is that if you embed the relfilenode or tablespace or
>> database in the encryption IV, you then need to then make sure you
>> re-encrypt any files that move between these. I am hesitant to do that
>> since it then requires these workarounds for encryption going forward.
>> We know that most people will not be using encryption, so that will not
>> be well tested either. For pg_upgrade, I used a minimal-impact
>> approach, and it has allowed dramatic changes in our code without
>> requiring changes and retesting of pg_upgrade.
>
>
> Will there be a per-relation salt stored in a separate file? I saw it mentioned in a few places (most recently https://www.postgresql.org/message-id/aa386c3f-fb89-60af-c7a3-9263a633ca1a%40postgresql.org) but there's also discussion of trying to make the TDEK unique without a separate salt so I'm unsure.
>
> With a per-relation salt there is no need to include fixed attributes (database, relfilenode, or tablespace) to ensure the derived key is unique per relation. A long salt (32-bytes from /dev/urandom) alone guarantees that uniqueness. Copying or moving files would then be possible by also copying the salt. It does not need to be a salt per file on disk either, one salt can be used for many files for the same relation by including the fork number, type, or segment in the TDEK derivation (so each file on disk for that relation ends up with a unique TDEK).

If we can derive unique TDEK using (database, tablespace, relfilenode)
as info I think it's better to use it rather than using random salt
per relations since it doesn't require additional information we need
to store. As described in HKDF RFC[1], if the input key is already
present as a cryptographically strong key we can skip the extract part
where use a salt.

[1] https://tools.ietf.org/html/rfc5869

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center