Re: XTS cipher mode for cluster file encryption

Greetings,

* Yura Sokolov (y(dot)sokolov(at)postgrespro(dot)ru) wrote:
> В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет:
> > * Yura Sokolov (y(dot)sokolov(at)postgrespro(dot)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.
>
> Why? I see no points to do it after. Why not XTS after Adiantum?
>
> Ok, I see one: XTS is standartized.

That's certainly one aspect of it. It's also more easily available to
us, and frankly the people working on this and writing the patches have
a better understanding of XTS from having looked into it. That it's
also more widely used is another reason.

> > > 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.
>
> Integrity could be based on simple non-cryptographic checksum, and it could
> be checked after decryption. It would be imposible to intentionally change
> encrypted page in a way it will pass checksum after decription.

No, it wouldn't be impossible when we're talking about non-cryptographic
checksums. That is, in fact, why you'd call them that. If it were
impossible (or at least utterly impractical) then you'd be able to claim
that it's cryptographic-level integrity validation.

> Currently we have 16bit checksum, and it is very small. But having larger
> checksum is orthogonal (ie doesn't bound) to having encryption.

Sure, but that would also require a page-format change. We've pointed
out the downsides of that and what it would prevent in terms of
use-cases. That's still something that might happen but it would be a
different effort from this.

> In fact, Adiantum is easily made close to SIV construction:
> - just leave last 8/16 bytes zero. If after decription they are zero,
> then integrity check passed.
> That is because SIV and Adiantum are very similar in its structure:
> - SIV:
> -- hash
> -- then stream cipher
> - Adiantum:
> -- hash (except last 16bytes)
> -- then encrypt last 16bytes with hash,
> -- then stream cipher
> -- then hash.
> If last N (N>16) bytes is nonce + zero bytes, then "hash, then encrypt last
> 16bytes with hash" become equivalent to just "hash", and Adiantum became
> logical equivalent to SIV.

While I appreciate your interest in this, I don't think it makes sense
for us to try and implement something of our own- we're not
cryptographers. Best is to look at published guideance and what other
projects have had success doing, and that's what this thread has been
about.

> > > - 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.
>
> And among others Adiantum looks best: it is fast even without hardware
> acceleration, it provides whole block encryption (ie every bit depends
> on every bit) and it doesn't bound to plain-text format.

And it could still be added later as another option if folks really want
it to be. I've outlined why it makes sense to go with XTS first but I
don't mean that to imply that we'll only ever have that. Indeed, once
we've actually got something, adding other methods will almost certainly
be simpler. Trying to do everything from the start will make this very
difficult to accomplish though.

Thanks,

Stephen