Greetings,
* Yura Sokolov (y.sokolov@postgrespro.ru) wrote:
> В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет:
> > 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].
That sounds like a great thing to think about adding ... after we get
something in that's based on XTS.
> 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.
The advantage of GCM-SIV is that it provides integrity as well as
confidentiality.
> - like XTS it doesn't need to change plain text format and doesn't need in
> additional Nonce/Auth Code.
Sure, in which case it's something that could potentially be added later
as another option in the future. I don't think we'll always have just
one encryption method and it's good to generally think about what it
might look like to have others but I don't think it makes sense to try
and get everything in all at once.
Thanks,
Stephen