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

В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет:
> 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.

Why? I see no points to do it after. Why not XTS after Adiantum?

Ok, I see one: XTS is standartized.

> > 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. 

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

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.

> > - 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.

> Thanks,
> 
> Stephen

regards,

Yura

PS. Construction beside SIV and Adiantum could be used with XTS as well.
I.e. instead of AES-GCM-SIV it could be AES-XTS-SIV.
And same way AES-XTS could be used instead of Chacha12 in Adiantum.