Re: XTS cipher mode for cluster file encryption

Greetings,

* Sasasu (i(at)sasa(dot)su) wrote:
> 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.

Tables and databases are handled differently, yes.

With ALTER TABLE SET TABLESPACE, we're allocating a new refilenode and
WAL'ing the table as FPIs. What happens with databases is fundamentally
different- no one is allowed to be connected to the database being moved
and we write a single 'database changed tablespace' record in the WAL
for this case. When it comes to TDE, this probably is actually helpful
as we're going to likely want the relfilenode to be included as part of
the IV.

> 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."

I don't like the idea of "CTR-like". What's wrong with using CTR for
WAL encryption? Based on the available information, that seems like the
exact use-case for CTR.

> The point of disagreement between you and me is only on the block-based API.

I'm glad to hear that, at least.

Thanks,

Stephen