Re: storing an explicit nonce

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>
Subject: Re: storing an explicit nonce
Date: 2021-05-26 01:16:12
Message-ID: 20210526011612.GO3048@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 25, 2021 at 08:03:14PM -0400, Stephen Frost wrote:
> Indeed they are, but that's not relevant to the thrust of this specific
> debate.
>
> Bruce is arguing that because clog is unprotected that it's not useful
> to protect relation data, with regard to data integrity validation as
> provided by AES-GCM using/storing tags. I dispute this, as relation
> data is primary data while clog, for all its value, is still metadata.
> Yes, impacting the metadata has an impact on the primary data, but it
> doesn't *change* that primary data at its core (and it's also more
> likely to be detected than random bit flipping in the relation data
> would be, which is possible if you're only encrypting and not providing
> any integrity validation).

Even if you can protect clog, this documentation paragraph makes it
clear that if you can modify the cluster, you can weaken security enough
to read and write any data you want:

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.

I know of no way to make that safer, so again, I don't see the value in
modification detection. Maybe someday we would find a way, but it seems
so remote as to not warrant consideration.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-05-26 01:16:18 Re: fdatasync performance problem with large number of DB files
Previous Message houzj.fnst@fujitsu.com 2021-05-26 01:05:05 RE: Skip partition tuple routing with constant partition key