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

From Stephen Frost
Subject Re: storing an explicit nonce
Date
Msg-id 20211007165712.GE20998@tamriel.snowman.net
Whole thread Raw
In response to Re: storing an explicit nonce  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: storing an explicit nonce  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Oct 7, 2021 at 11:45 AM Bruce Momjian <bruce@momjian.us> wrote:
> > I continue to be concerned that a page format change will decrease the
> > desirability of this feature by making migration complex and increasing
> > its code complexity.  I am unclear if it is necessary.
> >
> > I think the big question is whether XTS with db/relfilenode/blocknumber
> > is sufficient as an IV without a nonce that changes for updates.
>
> Those are fair concerns. I think I agree with everything you say here.
>
> There was some discussion earlier (not sure if it was on this thread)
> about integrity verification. And I don't think that there's any way
> we can do that without storing some kind of integrity verifier in each
> page. And if we're doing that anyway to support that feature, then
> there's no problem if it also includes the IV. I had read Stephen's
> previous comments to indicate that he thought we should go this way,
> and it sounded cool to me, too. However, it does make migrations
> somewhat more complex, because you would then have to actually
> dump-and-reload, rather than, perhaps, just encrypting all the
> existing pages while the cluster was offline. Personally, I'm not that
> fussed about that problem, but I'm also rarely the one who has to help
> people migrate to new releases, so I may not be as sympathetic to
> those problems there as I should be.

Yes, for integrity verification (also known as 'authenticated
encryption') we'd definitely need to store a larger nonce value.  In the
very, very long term, I think it'd be great to have that, and the patch
proposed on this thread seems really cool as a way to get us there.

> If we don't care about the integrity verification features, then as
> you say the next question is whether it's acceptable to use a
> predictable nonce that is computing from values that can be known
> without looking at the block contents. If so, we can forget about
> $SUBJECT and save ourselves some engineering work. If not, then I
> think we need to do $SUBJECT anyway. And so far I am not really
> convinced that we know which of those two things is the case. I don't,
> anyway.

Having TDE, even without authenticated encryption, is certainly
valuable.  Reducing the amount of engineering required to get there is
worthwhile.  Implementing TDE w/ XTS or similar, provided we do agree
that we can do so with an IV that we don't need to find additional space
for, would avoid that page-level format change.  I agree we should do
some research to make sure we at least have a reasonable answer to that
question.  I've spent a bit of time on that and haven't gotten to a sure
answer one way or the other as yet, but will continue to look.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: storing an explicit nonce
Next
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)