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

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Oct 12, 2021 at 08:25:52AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > > > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian <bruce@momjian.us> wrote:
> > > >
> > > >     > Yes, that's the direction that I was thinking also and specifically with
> > > >     > XTS as the encryption algorithm to allow us to exclude the LSN but keep
> > > >     > everything else, and to address the concern around the nonce/tweak/etc
> > > >     > being the same sometimes across multiple writes.  Another thing to
> > > >     > consider is if we want to encrypt zero'd page.  There was a point
> > > >     > brought up that if we do then we are encrypting a fair bit of very
> > > >     > predictable bytes and that's not great (though there's a fair bit about
> > > >     > our pages that someone could quite possibly predict anyway based on
> > > >     > table structures and such...).  I would think that if it's easy enough
> > > >     > to not encrypt zero'd pages that we should avoid doing so.  Don't recall
> > > >     > offhand which way zero'd pages were being handled already but thought it
> > > >     > made sense to mention that as part of this discussion.
> > > >
> > > >     Yeah, I wanted to mention that.  I don't see any security difference
> > > >     between fully-zero pages, pages with headers and no tuples, and pages
> > > >     with headers and only a few tuples.  If any of those are insecure, they
> > > >     all are.  Therefore, I don't see any reason to treat them differently.
> > > >
> > > >
> > > > We had to special case zero pages and not encrypt them because as far as I can
> > > > tell, there is no atomic way to extend a file and initialize it to Enc(zero) in
> > > > the same step.
> > >
> > > Oh, good point.  Yeah, we will need to handle that.
> >
> > Not sure what's meant here by 'handle that', but I don't see any
> > particular reason to avoid doing exactly the same for zero pages with
> > TDE in core..?  I don't think there's any reason we need to make things
> > complicated to ensure that we encrypt entirely empty pages.
>
> I thought he was saying that when you extend a file, you might have to
> extend it with all zeros, rather than being able to extend it with
> an actual encrypted page of zeros.  For example, I think when a page is
> corrupt in storage, it reads back as a fully zero page, and we would
> need to handle that.  Are you saying we already have logic to handle
> that so we don't need to change anything?

When we extend a file, it gets extended with all zeros.  PG already
handles that case, PG w/ TDE would need to also recognize that case
(which is what Ants was saying their patch does) and handle it.  In
other words, we just need to realize when a page is all zeros and not
try to decrypt it when we're reading it.  Ants' patch does that and my
recollection is that it wasn't very complicated to do, and that seems
much simpler than trying to figure out a way to ensure we do encrypt a
zero'd page as part of extending a file.

Thanks,

Stephen