Message-ID: <cbe62cdc-379f-db62-20a4-17097ebd780d@enterprisedb.com>
Date: Tue, 7 Dec 2021 16:39:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Transparent column encryption
Content-Language: en-US
To: Jacob Champion <pchampion@vmware.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <89157929-c2b6-817b-6025-8e4b2d89d88f@enterprisedb.com>
 <d18fdd364899dc60f1aa17eabc2376e4110fc8bc.camel@vmware.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <d18fdd364899dc60f1aa17eabc2376e4110fc8bc.camel@vmware.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/cbe62cdc-379f-db62-20a4-17097ebd780d%40enterprisedb.com>
Precedence: bulk

On 06.12.21 21:44, Jacob Champion wrote:
> I think reusing a zero IV will potentially leak more information than
> just equality, depending on the cipher in use. You may be interested in
> synthetic IVs and nonce-misuse resistance (e.g. [1]), since they seem
> like they would match this use case exactly. (But I'm not a
> cryptographer.)

I'm aware of this and plan to make use of SIV.  The current 
implementation is just an example.

> Have you given any thought to AEAD? As a client I'd like to be able to
> tie an encrypted value to other column (or external) data. For example,
> AEAD could be used to prevent a DBA from copying the (encrypted) value
> of my credit card column into their account's row to use it.

I don't know how that is supposed to work.  When the value is encrypted 
for insertion, the client may know things like table name or column 
name, so it can tie it to those.  But it doesn't know what row it will 
go in, so you can't prevent the value from being copied into another 
row.  You would need some permanent logical row ID for this, I think. 
For this scenario, the deterministic encryption mode is perhaps not the 
right one.

>> This is not targeting PostgreSQL 15.  But I'd appreciate some feedback
>> on the direction.
> 
> What kinds of attacks are you hoping to prevent (and not prevent)?

The point is to prevent admins from getting at plaintext data.  The 
scenario you show is an interesting one but I think it's not meant to be 
addressed by this.  If admins can alter the database to their advantage, 
they could perhaps increase their account balance, create discount 
codes, etc. also.

If this is a problem, then perhaps a better approach would be to store 
parts of the data in a separate database with separate admins.