Postgres Pro
Downloads
Home   >   mailing lists

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

From Ants Aasma
Subject Re: storing an explicit nonce
Date
Msg-id CANwKhkM4jQH=P+G7-LtmUw2wbtAPqOJx9VLv2cqc++9Qd7KZiw@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  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Tree view
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(). 

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

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?gr
Next
From: Dilip Kumar
Date:
Subject: Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable