public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: XTS cipher mode for cluster file encryption
Date: Sun, 17 Oct 2021 23:11:49 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>



On 10/16/21 16:16, Bruce Momjian wrote:
> 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.
> 

Would it really be that complex? Reserving a bunch of bytes at the end 
of each encrypted page (a bit like the "special" space, but after 
encryption) seems fairly straightforward. And I don't quite see why 
would this have a measurable impact, given the nonce is 16B at most. The 
encryption is likely way more expensive.

Moreover, it seems fairly reasonable to trade a bit of code complexity 
for something LSN-based which seems simpler but apparently has various 
weak points and is much harder to reason about.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

view thread (54+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: XTS cipher mode for cluster file encryption
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox