Re: XTS cipher mode for cluster file encryption - Mailing list pgsql-hackers

В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> Greetings,
> 
> I really don't think this is necessary.  Similar to PageSetChecksumCopy
> and PageSetChecksumInplace, I'm sure we would have functions which are
> called in the appropriate spots to do encryption (such as 'encrypt_page'
> and 'encrypt_block' in the Cybertec patch) and folks could review those
> in relative isolation to the rest.  Dealing with blocks in PG is already
> pretty well handled, the infrastructure that needs to be added is around
> handling temporary files and is being actively worked on ... if we could
> move past this debate around if we should be adding support for XTS or
> if only GCM-SIV would be accepted.
> 
> .....
> 
> 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.
> 
> .....
> 
> 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.
> 

Instead of debatting XTS vs GCM-SIV I'd suggest Google's Adiantum [1][2]
[3][4].

It is explicitely created to solve large block encryption issue - disk
encryption. It is used to encrypt 4kb at whole, but in fact has no
(practical) limit on block size: it is near-zero modified to encrypt 1kb
or 8kb or 32kb.

It has benefits of both XTS and GCM-SIV:
- like GCM-SIV every bit of cipher text depends on every bit of plain text
- therefore like GCM-SIV it is resistant to IV reuse: it is safe to reuse
  LSN+reloid+blocknumber tuple as IV even for hint-bit changes since every
  block's bit will change.
- like XTS it doesn't need to change plain text format and doesn't need in
  additional Nonce/Auth Code.

Adiantum stands on "giant's shoulders": AES, Chacha and Poly1305.
It is included into Linux kernel since 5.0 .

Adiantum/HPolyC approach (hash+cipher+stream-cipher+hash) could be used
with other primitives as well. For example, Chacha12 could be replaces
with AES-GCM or AES-XTS with IV derived from hash+cipher.

[1] https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html
[2] https://en.wikipedia.org/wiki/Adiantum_(cipher)
[3] https://tosc.iacr.org/index.php/ToSC/article/view/7360
[4] https://github.com/google/adiantum
[5]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=059c2a4d8e164dccc3078e49e7f286023b019a98

-------

regards
Yura Sokolov
y.sokolov@postgrespro.ru
funny.falcon@gmail.com