Re: storing an explicit nonce

On Wed, May 26, 2021 at 04:26:01PM -0700, Andres Freund wrote:
> 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?

Yes, I don't think protecting from write access is a realistic goal at
this point, and frankly ever. I think write access protection needs
all-cluster-file encryption. This is documented:

https://github.com/postgres/postgres/compare/master..bmomjian:_cfe-01-doc.patch

Cluster file encryption does not protect against unauthorized
file system writes. Such writes can allow data decryption if
used to weaken the system's security and the weakened system is
later supplied with the externally-stored cluster encryption key.
This also does not always detect if users with write access remove
or modify database files.

If this needs more text, let me know.

> 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?

Are you asking about this C commention in relation to the discussion
above, or is it an independent question? Are asking what it means?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

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