Re: Transparent column encryption - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Transparent column encryption
Date
Msg-id CAAWbhmiKM-xdWc37rJcstgTfQD-TrqX9jZpavDtisYdgv7t97w@mail.gmail.com
Whole thread Raw
In response to Re: Transparent column encryption  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15 (typo)
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: psql: show current user in prompt