dandraper

It's a good idea. CBC without verification is vulnerable as well. An attacker can modify the IV and the value will still decrypt. It's quite easy to change a what plaintext will pop out the other side and the client will be none-the-wiser.

Depends on what kinds of data you're encrypting but if its anything to do with money or health data authenticity is a must.

The security properties become much more interesting when the data remains encrypted when it leaves the database. For example, an ETL process doesn't necessarily need to know what data is, just the structure. Transferring data between systems can remain encrypted the whole time.

Homomorphic is literally hundreds of thousands of times slower than operations on plaintext. A comparison of 2 64-bit integers can take around > 50ms. So even with a b-tree where maybe ~100 comparisons could occur, the query will take 5s. A linear scan over 1m records would take 13 hours!

SSE, ORE, STE schemes are all far more practical.

The only problem with KMS in this model is that to get that auditability you need a data key per value/record. That means every decryption requires a request to KMS as it does not (and likely won't ever) support batched requests. We tried this for ages and the performance was terrible. < 100ms queries blew out to over 3 or 4 seconds.

If you're using AES in GCM mode? Bad...like catastrophic. An attacker can reveal the key.

If you want to use constant IV for deterministic (exact) lookups. Make sure you use AES in SIV mode which is resistant to IV reuse or CBC mode with an HMAC tag. Its slower than GCM unfortunately but one of the only secure options when you want to use deterministic option.

This stuff is hard to get right and can bite you in subtle and unexpected ways.

Key management and ability to support SQL/searching are the 2 biggest considerations.

`pg_enquo` uses Block ORE which is reasonably secure but results in very large (like 100x) ciphertext sizes. For an alternative (also written in Rust) check out https://ore.rs. It will soon support variable block sizes for smaller encrypted values.

If you want to do partial text queries or LIKE, you'll need a Searchable Symmetric Encryption (SSE) or Structured Encryption (STE) scheme. There are literally dozens of these schemes out there, each with their own tradeoffs so it can be hard to choose (Seny Kamara alone has published several: https://cs.brown.edu/people/seny/papers/).

Amazon KMS (and Google/Azure equivalents) all require a network request per encryption unless you cache/reuse keys. To put that into perspective, 1 query with 3 fields encrypted and 100 rows returned would result in 300 separate network requests.

You can use data-key caching to reuse a data key for many records to improve encryption performance. However decryption performance tends not to improve much because data-keys because they likely won't be uniformly used across your data set. Not to mention that you lose the ability to apply controls to records based on data key.

At CipherStash, we created Tandem (https://cipherstash.com/products/tandem) which uses a revised version of ORE, STE and fast key (bulk-ops) management to encrypt columns of your choosing. The core encryption is AES-256-GCM and the whole thing is written in Rust. It runs as a Docker container or standalone binary. We are working on WASM support as well as a separate Rust SDK. Most SQL queries "just work" and performance overhead is tiny (< 10ms per request).

Tandem is in preview and will be generally available at the end of November.

For some other gotchas when doing encryption in Postgres, I did a talk at Linux Conf last year (based on some ideas from Paul Grubbs et al paper of the same name): https://www.youtube.com/watch?v=JD8dtLjhmAM

Absolutely! FHE isn't practical for most applications.

Not yet but that's a good suggestion! The core client code is Rust so additional languages are (mostly) just native bindings to Rust. We will be releasing the Rust SDK publicly soon and welcome contributions!

Its not Homomorphic but "structural encryption". Less useful than HE but faster.

This feature is a result of MongoDB's acquisition of Aroki. It looks like a good product but we actually beat them to it with https://cipherstash.com/activestash

CipherStash works with any Database and also supports Range queries and sorting/ordering. We do it in the application layer. Only supports Ruby so far but C#, Java, Python, Rust are in the works.

I love this concept. Mail platforms are just another place where sensitive data has to be managed!