public inbox for [email protected]
help / color / mirror / Atom feedFrom: Stephen Frost <[email protected]>
To: Sasasu <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: XTS cipher mode for cluster file encryption
Date: Fri, 22 Oct 2021 11:36:37 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CA+TgmoaMHLXrxOj1HA+K=Z_qqgZUOpfdto8+QiVXsfP0ds+ojw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Greetings,
* Sasasu ([email protected]) 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
Attachments:
[application/pgp-signature] signature.asc (819B, ../[email protected]/2-signature.asc)
download
view thread (54+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: XTS cipher mode for cluster file encryption
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox