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...
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...