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

From Bruce Momjian
Subject Re: storing an explicit nonce
Date
Msg-id 20211013150022.GB2354@momjian.us
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Oct 13, 2021 at 09:16:37AM -0400, Stephen Frost wrote:
> Greetings,
> 
> * Ants Aasma (ants@cybertec.at) wrote:
> > On Wed, 13 Oct 2021 at 02:20, Bruce Momjian <bruce@momjian.us> wrote:
> > > On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> > > > On Wed, 13 Oct 2021 at 00:25, Bruce Momjian <bruce@momjian.us> wrote:
> > > >
> > > >     On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > > >     > Page encrypting to all zeros is for all practical purposes
> > > impossible to
> > > >     hit.
> > > >     > Basically an attacker would have to be able to arbitrarily set the
> > > whole
> > > >     > contents of the page and they would then achieve that this page
> > > gets
> > > >     ignored.
> > > >
> > > >     Uh, how do we know that valid data can't produce an encrypted
> > > all-zero
> > > >     page?
> > > >
> > > >
> > > > Because the chances of that happening by accident are equivalent to
> > > making a
> > > > series of commits to postgres and ending up with the same git commit
> > > hash 400
> > > > times in a row.
> > >
> > > Yes, 256^8192 is 1e+19728, but why not just assume a page LSN=0 is an
> > > empty page, and if not, an error?  Seems easier than checking if each
> > > page contains all zeros every time.
> > >
> > 
> > We already check it anyway, see PageIsVerifiedExtended().
> 
> Right- we check the LSN along with the rest of the page there.

Very good.  I have not looked at the Cybertec patch recently.

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

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: Robert Haas
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname