Re: storing an explicit nonce

Hi,

On 2021-05-26 07:14:47 +0200, Antonin Houska wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Tue, May 25, 2021 at 04:48:21PM -0700, Andres Freund wrote:
> > My point was about whether we need to change the nonce, and hence
> > WAL-log full page images if we change hint bits. If we don't and
> > reencrypt the page with the same nonce, don't we only expose the hint
> > bits? I was not suggesting we avoid changing the nonce in non-hint-bit
> > cases.
> >
> > I don't understand your computation above. You decrypt the page into
> > shared buffers, you change a hint bit, and rewrite the page. You are
> > re-XOR'ing the buffer copy with the same key and nonce. Doesn't that
> > only change the hint bits in the new write?

Yea, I had a bit of a misfire there. Sorry.

I suspect that if we try to not disclose data if an attacker has write
access, this still leaves us with issues around nonce reuse, unless we
also employ integrity measures. Particularly due to CTR mode, which
makes it easy to manipulate individual parts of the encrypted page
without causing the decrypted page to be invalid. E.g. the attacker can
just update pd_upper on the page by a small offset, and suddenly the
replay will insert the tuple at a slightly shifted offset - which then
seems to leak enough data to actually analyze things?

As the patch stands that seems trivially doable, because as I read it,
most of the page header is not encrypted, and checksums are done of the
already encrypted data. But even if that weren't the case, brute forcing
16bit worth of checksum isn't too bad, even though it would obviously
make an attack a lot more noisy.

https://github.com/bmomjian/postgres/commit/7b43d37a5edb91c29ab6b4bb00def05def502c33#diff-0dcb5b2f36c573e2a7787994690b8fe585001591105f78e58ae3accec8f998e0R92
/*
* Check if the page has a special size == GISTPageOpaqueData, a valid
* GIST_PAGE_ID, no invalid GiST flag bits are set, and a valid LSN. This
* is true for all GiST pages, and perhaps a few pages that are not. The
* only downside of guessing wrong is that we might not update the LSN for
* some non-permanent relation page changes, and therefore reuse the IV,
* which seems acceptable.
*/

Huh?

Regards,

Andres