On Fri, 2021-12-03 at 22:32 +0100, Peter Eisentraut wrote:
> This feature does support deterministic
> encryption as an alternative to the default randomized encryption, so
> in that mode you can do equality lookups, at the cost of some
> security.
> + if (enc_det)
> + memset(iv, ivlen, 0);
I think reusing a zero IV will potentially leak more information than
just equality, depending on the cipher in use. You may be interested in
synthetic IVs and nonce-misuse resistance (e.g. [1]), since they seem
like they would match this use case exactly. (But I'm not a
cryptographer.)
> The encryption algorithms are mostly hardcoded right now, but there
> are facilities for picking algorithms and adding new ones that will be
> expanded. The CMK process uses RSA-OAEP. The CEK process uses
> AES-128-CBC right now; a more complete solution should probably
> involve some HMAC thrown in.
Have you given any thought to AEAD? As a client I'd like to be able to
tie an encrypted value to other column (or external) data. For example,
AEAD could be used to prevent a DBA from copying the (encrypted) value
of my credit card column into their account's row to use it.
> This is not targeting PostgreSQL 15. But I'd appreciate some feedback
> on the direction.
What kinds of attacks are you hoping to prevent (and not prevent)?
--Jacob
[1] https://datatracker.ietf.org/doc/html/rfc8452