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

From Ants Aasma
Subject Re: storing an explicit nonce
Date
Msg-id CANwKhkOorCskbrKAqTJr7u--6G0zQkW+O2MLG+apUTYX08D9oQ@mail.gmail.com
Whole thread Raw
In response to Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Responses Re: storing an explicit nonce
List pgsql-hackers
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.

--
Ants Aasma
Senior Database Engineer
www.cybertec-postgresql.com

pgsql-hackers by date:

Previous
From: bt21tanigaway
Date:
Subject: Re: Printing backtrace of postgres processes
Next
From: Sergey Shinderuk
Date:
Subject: Re: Bug in DefineRange() with multiranges