Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, May 27, 2021 at 04:09:13PM -0400, Stephen Frost wrote:
> > The above article, at least, suggested encrypting the sector number
> > using the second key and then multiplying that times 2^(block number),
> > where those blocks were actually AES 128bit blocks. The article further
> > claims that this is what's used in things like Bitlocker, TrueCrypt,
> > VeraCrypt and OpenSSL.
> >
> > While the documentation isn't super clear, I'm taking that to mean that
> > when you actually use EVP_aes_128_xts() in OpenSSL, and you provide it
> > with a 256-bit key (twice the size of the AES key length function), and
> > you give it a 'tweak', that what you would actually be passing in would
> > be the "sector number" in the above method, or for us perhaps it would
> > be relfilenode+block number, or maybe just block number but it seems
> > like it'd be better to include the relfilenode to me.
>
> If you go in that direction, you should make sure pg_upgrade preserves
> what you use (it does not preserve relfilenode, just pg_class.oid), and
> CREATE DATABASE still works with a simple file copy.
Ah, yes, good point, if we support in-place pg_upgrade of an encrypted
cluster then the tweak has to be consistent between the old and new.
I tend to agree with Andres that it'd be reasonable to make CREATE
DATABASE do a bit more work for an encrypted cluster though, so I'm less
concerned about that.
Using pg_class.oid instead of relfilenode seems likely to complicate
things like crash recovery though, wouldn't it? I wonder if there's
something else we could use.
Thanks,
Stephen