Re: storing an explicit nonce

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Ants Aasma <ants(at)cybertec(dot)at>, Sasasu <i(at)sasa(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: storing an explicit nonce
Date: 2021-10-07 16:57:12
Message-ID: 20211007165712.GE20998@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Oct 7, 2021 at 11:45 AM Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-10-07 16:58:57 Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Previous Message Bruce Momjian 2021-10-07 16:56:22 Re: storing an explicit nonce