Message-ID: <e0690db6-5d11-b32a-0be2-925169eebbf3@enterprisedb.com>
Date: Sun, 17 Oct 2021 23:23:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.1.0
Subject: Re: XTS cipher mode for cluster file encryption
Content-Language: en-US
To: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>
Cc: Stephen Frost <sfrost@snowman.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <20211013222648.GA373@momjian.us>
 <20211015192248.GP20998@tamriel.snowman.net>
 <80dddd73-ae23-0481-53ad-d37f8b51c86a@enterprisedb.com>
 <20211016141625.GA8190@momjian.us>
 <20211016161505.jj3uoe75avwo6vbk@alap3.anarazel.de>
 <20211016162851.GB8190@momjian.us>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <20211016162851.GB8190@momjian.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/e0690db6-5d11-b32a-0be2-925169eebbf3%40enterprisedb.com>
Precedence: bulk

On 10/16/21 18:28, Bruce Momjian wrote:
> On Sat, Oct 16, 2021 at 09:15:05AM -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2021-10-16 10:16:25 -0400, Bruce Momjian wrote:
>>> As a final comment to Andres's email, adding a GCM has the problems
>>> above, plus it wouldn't detect changes to pg_xact, fsm, vm, etc, which
>>> could also affect the integrity of the data.  Someone could also restore
>>> and old copy of a patch to revert a change, and that would not be
>>> detected even by GCM.
>>
>>> I consider this a checkbox feature and making it too complex will cause
>>> it to be rightly rejected.
>>
>> You're just deferring / hiding the complexity. For one, we'll need integrity
>> before long if we add encryption support. Then we'll deal with a more complex
>> on-disk format because there will be two different ways of encrypting. For
>> another, you're spreading out the security analysis to a lot of places in the
>> code and more importantly to future changes affecting on-disk data.
>>

I've argued for storing the nonce, but I don't quite see why would we 
need integrity guarantees?

AFAICS the threat model the patch aims to address is an attacker who can 
observe the data (e.g. a low-privileged OS user), but can't modify the 
files. Which seems like a reasonable model for shared environments.

IMO extending this to cases where the attacker can modify the data moves 
the goalposts quite significantly. And it's quite possible authenticated 
encryption would not be enough to prevent that, because that still works 
only at block level, and you can probably do a lot of harm with replay 
attacks (e.g. replacing blocks with older versions). And if you can 
modify the data directory / config files, what are the chances you can't 
just get access to the database, trace the processes or whatever?

We already have a way to check integrity by storing page checksum, but 
I'm not sure if that's good enough (there's a lot of subtle issues with 
building proper AEAD scheme).


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company