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
