11 ms·

I’m having a hard time wrapping my head around what guarantees this does and does not make. If you can run “select * where secret_col == 10”… why does it matte

by maxrmk 2mo ago

I’m having a hard time wrapping my head around what guarantees this does and does not make. If you can run “select * where secret_col == 10”… why does it matter that the column is encrypted?

nullbio 2mo ago
My thoughts as well. Seems like security theater.
aabhay 2mo ago
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.
- nicce 2mo ago
  A lot is allowed: https://cipherstash.com/docs/stack/cipherstash/encryption/searchable-encryption#supported-query-types https://cipherstash.com/docs/stack/cipherstash/encryption/se...
nicce 2mo ago
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.
- dandraper 2mo ago
  lol yeah. Just a side chain that I found on a weekend. 8 years and $10m later. Couldn’t possibly be real now could it?
dandraper 2mo ago
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 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/queries https://cipherstash.com/docs/stack/cipherstash/encryption/qu...
- hsbauauvhabzb 2mo ago
  What does all this actually solve? Presumably SQL injection might still decrypt contents and order by/where clause enumeration would still be possible regardless. Keys must be stored in memory, on-disk or via a secret server meaning column encryption would not mitigate the impact of RCE/full shell compromise. Add in the cost of column level encryption when querying large volumes of data, this seems to be entirely angled at gold plated compliance security theatre rather than solving any actual problem.
  - repeekad 2mo ago
    Careful, they’ll take “gold plated compliance security” and use it in sales pitches
    - dandraper 2mo ago
      If we do, I'll be sure to attribute it to this thread :p
  - dandraper 2mo ago
    See above but some additional points: Keys are not stored in the database or in the application. Every data key is derived at query time via a 2-party system: 1. by the key server which manages root-key material (stored in an HSM or traditional KMS) 2. keys derived via a user credential at the time of the query SQL Injection case: An adversary signs up to your app, pulls of a SQLi and you might think that the app will just decrypt the values. It won't because the adversary's auth cred can't derive keys to decrypt anything but the data they are explicitly allowed to access. RCE/shell compromise: Because keys are derived on demand these kinds of attacks are largely inert. If the attacker could read memory from the running app on-demand then they could conceivably see credentials in flight but each key only ever decrypts one value so the blast radius is limited. On the cost of decryption: Queries typically only return a subset of the values in a table and, importantly, don't need to decrypt anything at all. Querying and decryption are independent. If you DO need to decrypt a large volume of data, CipherStash can do it at 10,000 values per second. Query performance is under 1ms for simple queries and no-more than 200-300ms for more complex queries. Full benches here: https://github.com/cipherstash/benches https://github.com/cipherstash/benches No security tool is perfect, nor "gold plated" but this tech meaningfully reduces blast area of attacks, makes many attacks inert and gives you an incredibly reliable audit trail.
MattPalmer1086 2mo ago
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.
- dandraper 2mo ago
  It is indeed the case.
dandraper 2mo ago
Because queries are encrypted, too. And you need to be authorized to encrypt a query term. That's the whole crux. TBH, I'm so close to this now I forget that part isn't obvious! You literally can't do: select * from blah where secret_col == 10 And get meaningful results. You can only do something like: select * from blah where secret_col == Encrypt(10); And in order to generate that encrypted query, you must be authorized. So an adversary can't simply do trial and error queries to guess records.

by maxrmk 2mo ago

I’m having a hard time wrapping my head around what guarantees this does and does not make. If you can run “select * where secret_col == 10”… why does it matter that the column is encrypted?

nullbio 2mo ago

My thoughts as well. Seems like security theater.

aabhay 2mo ago

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.

nicce 2mo ago
A lot is allowed: https://cipherstash.com/docs/stack/cipherstash/encryption/searchable-encryption#supported-query-types https://cipherstash.com/docs/stack/cipherstash/encryption/se...

nicce 2mo ago

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.

dandraper 2mo ago
lol yeah. Just a side chain that I found on a weekend. 8 years and $10m later. Couldn’t possibly be real now could it?

dandraper 2mo ago

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 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/queries https://cipherstash.com/docs/stack/cipherstash/encryption/qu...

hsbauauvhabzb 2mo ago
What does all this actually solve? Presumably SQL injection might still decrypt contents and order by/where clause enumeration would still be possible regardless. Keys must be stored in memory, on-disk or via a secret server meaning column encryption would not mitigate the impact of RCE/full shell compromise. Add in the cost of column level encryption when querying large volumes of data, this seems to be entirely angled at gold plated compliance security theatre rather than solving any actual problem.
- repeekad 2mo ago
  Careful, they’ll take “gold plated compliance security” and use it in sales pitches
  - dandraper 2mo ago
    If we do, I'll be sure to attribute it to this thread :p
- dandraper 2mo ago
  See above but some additional points: Keys are not stored in the database or in the application. Every data key is derived at query time via a 2-party system: 1. by the key server which manages root-key material (stored in an HSM or traditional KMS) 2. keys derived via a user credential at the time of the query SQL Injection case: An adversary signs up to your app, pulls of a SQLi and you might think that the app will just decrypt the values. It won't because the adversary's auth cred can't derive keys to decrypt anything but the data they are explicitly allowed to access. RCE/shell compromise: Because keys are derived on demand these kinds of attacks are largely inert. If the attacker could read memory from the running app on-demand then they could conceivably see credentials in flight but each key only ever decrypts one value so the blast radius is limited. On the cost of decryption: Queries typically only return a subset of the values in a table and, importantly, don't need to decrypt anything at all. Querying and decryption are independent. If you DO need to decrypt a large volume of data, CipherStash can do it at 10,000 values per second. Query performance is under 1ms for simple queries and no-more than 200-300ms for more complex queries. Full benches here: https://github.com/cipherstash/benches https://github.com/cipherstash/benches No security tool is perfect, nor "gold plated" but this tech meaningfully reduces blast area of attacks, makes many attacks inert and gives you an incredibly reliable audit trail.

MattPalmer1086 2mo ago

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.

dandraper 2mo ago
It is indeed the case.

dandraper 2mo ago

Because queries are encrypted, too. And you need to be authorized to encrypt a query term. That's the whole crux. TBH, I'm so close to this now I forget that part isn't obvious! You literally can't do: select * from blah where secret_col == 10 And get meaningful results. You can only do something like: select * from blah where secret_col == Encrypt(10); And in order to generate that encrypted query, you must be authorized. So an adversary can't simply do trial and error queries to guess records.