On 2021/10/22 01:28, Stephen Frost wrote:
> None of these are actually working with or changing the data though,
> they're just copying it. I don't think we'd actually want these to
> decrypt and reencrypt the data.
OK, but why ALTER TABLE SET TABLESPACE use smgrread() and smgrextend()
instead of copy_file().
TDE needs to modify these code paths, and make the patch bigger.
On 2021/10/22 01:28, Stephen Frost wrote:
> No, the CTR approach isn't great because, as has been discussed quite a
> bit already, using the LSN as the IV means that different data might be
> re-encrypted with the same LSN and that's not an acceptable thing to
> have happen with CTR.
On 2021/10/22 01:28, Stephen Frost wrote:
> Thankfully, for WAL
> (unlike heap and index blocks) we don't really have that issue- we
> hopefully aren't going to write different WAL records at the same LSN
> and so using the LSN there should be alright.
On 2021/10/22 01:28, Stephen Frost wrote:
> We've discussed at length how using CTR for heap isn't a good idea even
> if we're using the LSN for the IV, while if we use XTS then we don't
> have the issues that CTR has with IV re-use and using the LSN (plus
> block number and perhaps other things). Nothing in what has been
> discussed here has really changed anything there that I can see and so
> it's unclear to me why we continue to go round and round with it.
I am not re-discuss using CTR for heap table. I mean use some CTR-like
algorithm *only* for WAL encryption. My idea is exactly the same when
you are typing "we hopefully aren't going to write different WAL records
at the same LSN and so using the LSN there should be alright."
The point of disagreement between you and me is only on the block-based API.
On 2021/10/22 01:28, Stephen Frost wrote:
> it's unclear to me why we continue to go round and round with it.
same to me. I am monitoring this thread about 9 months, watching yours
discuss key management/CBC/CRT/GCM round and round.