On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni <sehr...@jackdb.com> wrote: > > On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian <br...@momjian.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
