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

On Tue, Oct 26, 2021 at 11:11:39PM +0200, Tomas Vondra wrote:
> BTW I'm not sure what the existing patches do, but I wonder if we should
> calculate the checksum before or after encryption. I'd say it should be
> after encryption, because checksums were meant as a protection against
> issues at the storage level, so the checksum should be on what's written to
> storage, and it'd also allow offline verification of checksums etc. (Of
> course, that'd make the whole idea of relying on our checksums even more
> futile.)
> 
> Note: Maybe there are reasons why the checksum needs to be calculated before
> encryption, not sure.

Yes, these are the tradeoffs --- allowing offline checksum checking
without requiring the key vs. giving _some_ integrity checking and
requiring the key.

> Yeah, I personally don't see much difference between XTS and Adiantum.
> 
> There are a bunch of benefits, but the main reason why Google developed it
> seems to be performance on low-end ARM machines (i.e. phones). Which is
> nice, but it's probably not hugely important - very few people run Pg on
> such machines, especially in performance-sensitive context.
> 
> It's true Adiantum is probably more resilient to IV reuse etc. but it's not
> like XTS is suddenly obsolete, and it certainly doesn't solve the integrity
> issue etc.
> 
> > > > > - 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.
> > 
> 
...
> So maybe the best thing is simply to roll with both - design the whole
> feature in a way that allows selecting the encryption scheme, with two
> options. That's generally a good engineering practice, as it ensures things
> are not coupled too much. And it's not like the encryption methods are
> expected to be super difficult.

I am not in favor of adding additional options to this feature unless we
can explain why users should choose one over the other.  There is also
the problem of OpenSSL not supporting Adiantum.

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

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