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

On Fri, Oct 15, 2021 at 10:57:03PM +0200, Tomas Vondra wrote:
> > That said, I don't think that's really a huge issue or something that's
> > a show stopper or a reason to hold off on using XTS.  Note that what
> > those bits actually *are* isn't leaked, just that they changed in some
> > fashion inside of that 16-byte cipher text block.  That they're directly
> > leaked with CTR is why there was concern raised about using that method,
> > as discussed above and previously.
> > 
> 
> Yeah. With CTR you pretty learn where the hint bits are exactly, while with
> XTS the whole ciphertext changes.
> 
> This also means CTR is much more malleable, i.e. you can tweak the
> ciphertext bits to flip the plaintext, while with XTS that's not really
> possible - it's pretty much guaranteed to break the block structure. Not
> sure if that's an issue for our use case, but if it is then neither of the
> two modes is a solution.

Yes, this is a vary good point.  Let's look at the impact of _not_ using
the LSN.  For CTR (already rejected) bit changes would be visible by
comparing old/new page contents.  For CBC (also not under consideration)
the first 16-byte block would show a change, and all later 16-byte
blocks would show a change.  For CBC, you see the 16-byte blocks change,
but you have no idea how many bits were changed, and in what locations
in the 16-byte block (AES uses substitution and diffusion).  For XTS,
because earlier blocks don't change the IV used by later blocks like
CBC, you would be able to see each 16-byte block that changed in the 8k
page.  Again, you would not know the number of bits changed or their
locations.

Do we think knowing which 16-byte blocks on an 8k page change would leak
useful information?  If so, we should use the LSN and just accept that
some cases might leak as described above.  If we don't care, then we can
skip the use of the LSN and simplify the patch.

> Not sure - it seems a bit weird to force LSN change even in cases that don't
> generate any WAL. I was not following the encryption thread and maybe it was
> discussed/rejected there, but I've always imagined we'd have a global nonce
> generator (similar to a sequence) and we'd store it at the end of each
> block, or something like that.

Storing the nonce in the page means more code complexity, possible
performance impact, and the inability to create standbys via binary
replication that use cluster file encryption.

As a final comment to Andres's email, adding a GCM has the problems
above, plus it wouldn't detect changes to pg_xact, fsm, vm, etc, which
could also affect the integrity of the data.  Someone could also restore
and old copy of a patch to revert a change, and that would not be
detected even by GCM.

I consider this a checkbox feature and making it too complex will cause
it to be rightly rejected.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.