Re: storing an explicit nonce

Hi,

On 2021-05-27 10:57:24 -0400, Bruce Momjian wrote:
> On Wed, May 26, 2021 at 04:26:01PM -0700, Andres Freund wrote:
> > 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.

Well, it's one thing to say that it's not a complete protection, and
another that a few byte sized writes to a single page are sufficient to
get access to encrypted data. And "all-cluster-file" encryption won't
help against the type of scenario I outlined.

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

The comment is blithely waving away a fundamental no-no (reusing nonces)
when using CTR mode as "acceptable".

Greetings,

Andres Freund