On 30.01.23 23:30, Jacob Champion wrote:
>>> The column encryption algorithm is set per-column -- but isn't it
>>> tightly coupled to the CEK, since the key length has to match? From a
>>> layperson perspective, using the same key to encrypt the same plaintext
>>> under two different algorithms (if they happen to have the same key
>>> length) seems like it might be cryptographically risky. Is there a
>>> reason I should be encouraged to do that?
>>
>> Not really. I was also initially confused by this setup, but that's how
>> other similar systems are set up, so I thought it would be confusing to
>> do it differently.
>
> Which systems let you mix and match keys and algorithms this way? I'd
> like to take a look at them.
See here for example:
https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15
>>> With the loss of \gencr it looks like we also lost a potential way to
>>> force encryption from within psql. Any plans to add that for v1?
>>
>> \gencr didn't do that either. We could do it. The libpq API supports
>> it. We just need to come up with some syntax for psql.
>
> Do you think people would rather set encryption for all parameters at
> once -- something like \encbind -- or have the ability to mix
> encrypted and unencrypted parameters?
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.
> 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. How would that deal with data
type extensibility, is an obvious question to start with. Don't know.
