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

From Stephen Frost
Subject Re: storing an explicit nonce
Date
Msg-id 20210525235811.GS20766@tamriel.snowman.net
Whole thread Raw
In response to Re: storing an explicit nonce  (Andres Freund <andres@anarazel.de>)
Responses Re: storing an explicit nonce
List pgsql-hackers
Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2021-05-25 17:04:50 -0400, Stephen Frost wrote:
> > I do think it's reasonable to consider having hint bits not included in
> > the encrypted part of the page and therefore remove the need to produce
> > a new nonce for each hint bit change.
>
> Huh. How are you going to track that efficiently? Do you want to mask
> them out before writing? As far as I understand you can't just
> re-encrypt a page with the same nonce, but different contents, without
> leaking information that you can't have leaked, even if the differences
> are not of a secret nature.

The simple thought I had was masking them out, yes.  No, you can't
re-encrypt a different page with the same nonce.  (Re-encrypting the
exact same page with the same nonce, however, just yields the same
cryptotext and therefore is fine).

> I don't think hint bits are the only way to end up with needing to
> re-write a page with slightly different content, but the same LSN,
> during recovery, after a crash.

Any other cases would have to be addressed if we were to use LSNs, of
course.

> I think it's just not going to fly to use LSNs as nonces, and that it's
> not worth butchering all kinds of aspect of the system to make it appear
> to work.

I do agree that we'd want to avoid "butchering all kinds of aspects of
the system" if possible. :)

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_rewind fails if there is a read only file.
Next
From: Andres Freund
Date:
Subject: Re: storing an explicit nonce