CipherStash founder here.

If a column is encrypted using standard encryption (like AES-GCM) then the values are non-deterministic and fully randomized. That means that if you encrypt the same value twice, you'll get 2 different ciphertexts.

So the query: select * where secret_col == 10

Would actualy be: select * where secret_col == encrypt_aes(10);

And values in secret_col will never match (because the output of encrypt_aes will be different every time, even for the same input).

A common way around this is to use deterministic encryption which eliminates the randomization at the cost of a slightly weaker security model. What leaks is the ability to see if any 2 plaintexts are equal (because they have the same ciphertext) - what you actually want in the case of search.

You have to be careful implementing deterministic encryption though: don't use AES-GCM with a fixed nonce because the scheme completely breaks. You can use CBC mode but then you lose authenticity. We use AES-GCM-SIV (synthetic IV which retains authentication but is secure under a fixed nonce) and HMAC (keyed hashing).

But there are approaches to solving queries like: -- range/order SELECT * FROM foo WHERE x > 10; SELECT * FROM foo ORDER BY x; -- fuzzy text SELECT * FROM foo WHERE name ~ "dan";

These capabilities are all based on public research: For example, order/range uses: https://eprint.iacr.org/2016/612.pdf

Our docs are quite limited at the moment (fixing as quickly as we can!) but you can see the current list of supported queries here: https://cipherstash.com/docs/stack/cipherstash/encryption/qu...

It sounds like someone has discovered a side-channel, made a project around it, and forget/did not know what side-channel originally means. And then someone at Supabase who does not know crypto, is a victim of their marketing.

One would hope that only users who can already decrypt the data can perform the queries. In that case, it would give much faster query performance without allowing inference attacks on the data.

If not, then a lot of the data could be easily reconstructed.

My thoughts as well. Seems like security theater.

you're probably only allowed a subset of the query language to talk to an encrypted table. E.g. only range queries that target a sample size > 5% of rows, etc., with exceptions for searches that hit an exact index such as looking up by id.