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