public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sasasu <[email protected]>
To: Stephen Frost <[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:35:38 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[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]>
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.
Attachments:
[application/pgp-keys] OpenPGP_0x4E72AF09097DAE2E.asc (7.9K, ../[email protected]/2-OpenPGP_0x4E72AF09097DAE2E.asc)
download
[application/pgp-signature] OpenPGP_signature (833B, ../[email protected]/3-OpenPGP_signature)
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