Greetings, * Bruce Momjian (br...@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
signature.asc
Description: PGP signature
