Re: Transparent column encryption

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.