Re: Key management with tests - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Key management with tests
Date
Msg-id 20210112181544.GS4320@momjian.us
Whole thread Raw
In response to Re: Key management with tests  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Key management with tests  (Stephen Frost <sfrost@snowman.net>)
Re: Key management with tests  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Jan 12, 2021 at 01:11:29PM -0500, Stephen Frost wrote:
> > I think one big question is that, since we are using a streaming cipher,
> > do we care about hint bit changes showing to users?  I actually don't
> > know.  If we do, some kind of dummy LSN record might be required, as you
> > suggested.
> 
> I don't think there's any doubt that we need to make sure that the IV is
> distinct and advancing the LSN to get a new one when needed for this
> case seems like it's probably the way to do that.  Hint bit change
> visibility to users isn't really at issue here- we can't use the same IV
> multiple times.  The two options that we have are to either not actually
> update the hint bit in such a case, or to make sure to change the
> LSN/IV.  Another option would be to, if we're able to make a hole to put
> the GCM tag on to the page somewhere, further widen that hole to include
> an additional space for a counter that would be mixed into the IV, to
> avoid having to do an XLOG NOOP.

Well, we have eight unused bits in the IV, so we could just increment
that for every hint bit change that uses the same LSN, and then force a
dummy WAL record when that 8-bit counter overflows --- that seems
simpler than logging hint bits.

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

  The usefulness of a cup is in its emptiness, Bruce Lee




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Moving other hex functions to /common
Next
From: Stephen Frost
Date:
Subject: Re: Key management with tests