From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Sasasu <i(at)sasa(dot)su> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XTS cipher mode for cluster file encryption |
Date: | 2021-10-25 06:59:17 |
Message-ID: | 48020c9811b72499aa5c4c4584b34ed33b75d1b0.camel@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)sokolov(at)postgrespro(dot)ru
funny(dot)falcon(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Amul Sul | 2021-10-25 07:04:23 | Re: [Patch] ALTER SYSTEM READ ONLY |
Previous Message | Michael Paquier | 2021-10-25 06:51:23 | Re: pg_receivewal starting position |