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.
