MIME-Version: 1.0
References: <89157929-c2b6-817b-6025-8e4b2d89d88f@enterprisedb.com>
 <48a9f2c2-4a57-27d8-7c53-16a23a01014e@enterprisedb.com> <79f08a39-a7da-5157-cef4-378fb60c18f8@enterprisedb.com>
 <258c5064-437e-f41e-7537-5e8c343c33cc@enterprisedb.com> <ddb316e8-a978-ee69-1edd-0ee82ecc6d8b@enterprisedb.com>
 <edb5eb1f-5818-5521-537d-20cf7f470742@enterprisedb.com> <6bd99fea-3298-854d-d37f-554151342f36@enterprisedb.com>
 <963aa100-7e78-3463-0645-700eaaa325f2@enterprisedb.com> <06830254-6d87-86b2-0280-bf2eee7736a5@enterprisedb.com>
 <a86c8d36-e9c5-cc5b-2c50-cc563d818419@enterprisedb.com> <75f394fa-f539-1875-079c-c654deceed41@enterprisedb.com>
 <8bcedb49-1496-0755-bd24-1cbabf30ec84@enterprisedb.com> <d9dd3634-6154-b0b7-f3a9-0d86dad7b8ff@enterprisedb.com>
 <bdb6433c-2d4e-8ae3-3bda-913f0b53fbb8@enterprisedb.com> <5003d222-5975-38c1-e471-888e642f23aa@timescale.com>
 <00b0c4f3-0d9f-dcfd-2ba0-eee5109b4963@enterprisedb.com> <CAAWbhmibyvZXu3P7vU8FjtUN-Jx86udDVjkt=fNQLuQgOBniXQ@mail.gmail.com>
 <8a1ccf22-2a86-f002-bbd8-49f56729a5f3@enterprisedb.com>
In-Reply-To: <8a1ccf22-2a86-f002-bbd8-49f56729a5f3@enterprisedb.com>
From: Jacob Champion <jchampion@timescale.com>
Date: Fri, 3 Feb 2023 12:43:24 -0800
Message-ID: <CAAWbhmiKM-xdWc37rJcstgTfQD-TrqX9jZpavDtisYdgv7t97w@mail.gmail.com>
Subject: Re: Transparent column encryption
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAAWbhmiKM-xdWc37rJcstgTfQD-TrqX9jZpavDtisYdgv7t97w%40mail.gmail.com>
Precedence: bulk

On Tue, Jan 31, 2023 at 5:26 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> See here for example:
> https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15

Hm. I notice they haven't implemented more than one algorithm, so I
wonder if they're going to be happy with their decision to
mix-and-match when number two arrives.

> For pg_dump, I'd like a mode that makes all values parameters of an
> INSERT statement.  But obviously not all of those will be encrypted.  So
> I think we'd want a per-parameter syntax.

Makes sense. Maybe something that defaults to encrypted with opt-out
per parameter?

    UPDATE t SET name = $1 WHERE id = $2
        \encbind "Jacob" plaintext(24)

> > More concretely: should psql allow you to push arbitrary text into an
> > encrypted \bind parameter, like it does now?
>
> We don't have any data type awareness like that now in psql or libpq.
> It would be quite a change to start now.

I agree. It just feels weird that a misbehaving client can "attack"
the other client implementations using it, and we don't make any
attempt to mitigate it.

--Jacob