Re: storing an explicit nonce - Mailing list pgsql-hackers

On Thu, May 27, 2021 at 12:49 PM Stephen Frost <sfrost@snowman.net> wrote:
> Right, if we simply can't solve the nonce-reuse concern then that would
> be better.

Given the issues that Andres raised about standbys and the treatment
of the "hole," I see using the LSN for the nonce as a dead-end. I
think it's pretty bad on performance grounds too, for reasons already
discussed, but you could always hypothesize that people care so much
about security that they will ignore any amount of trouble with
performance. You can hardly hypothesize that those same people also
won't mind security vulnerabilities that expose tuple data, though.

I don't think the idea of storing the nonce at the end of the page is
dead. There seem to be some difficulties there, but I think there are
reasonable prospects of solving them. At the very least there's the
brute-force approach of generating a ton of cryptographically strong
random numbers, and there seems to be some possibility of doing better
than that.

However, I'm pretty excited by this idea of using XTS. Now granted I
didn't have the foggiest idea what XTS was before today, but I hear
you and Andres saying that we can use that approach without needing a
nonce at all. That seems to make a lot of the problems we're talking
about here just go away.

> > Nor does it provide integrity - which does seem like a significant issue
> > going forward. Which does require storing additional per-page data...
>
> Yeah, this is one of the reasons that I hadn't really been thrilled with
> XTS- I've really been looking down the road at eventually having GCM and
> having actual integrity validation included.
>
> That's not really a reason to rule it out though and Bruce's point about
> having a way to get to an encrypted cluster from an unencrypted one is
> certainly worth consideration.  Naturally, we'd need to document
> everything appropriately but there isn't anything saying that we
> couldn't, say, have XTS in v15 without any adjustments to the page
> layout, accepting that there's no data integrity validation and focusing
> just on encryption, and then returning to the question about adding in
> data integrity validation for a future version, perhaps using the
> special area for a nonce+tag with GCM or maybe something else.  Users
> who wish to move to a cluster with encryption and data integrity
> validation would have to get there through some other means than
> replication, but that's going to always be the case because we have to
> have space to store the tag, even if we can figure out some other
> solution for the nonce.

+1 from me to all of this except the idea of foreclosing present
discussion on how data-integrity validation could be made to work. I
think it would great to have more discussion of that problem now, in
case it informs our decisions about anything else, especially because,
based on your earlier remarks, it seems like there is some coupling
between the two problems.

-- 
Robert Haas
EDB: http://www.enterprisedb.com