Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Searchable field-level encryption on Supabase with CipherStash

supabase.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: Searchable field-level encryption on Supabase with CipherStash

#11

Post by dandraper »

jph wrote: post #4

> Anywhere you need direct database access outside your application, CipherStash Proxy provides a secure escape hatch. This sounds like a back door. Is it? To me, the whole article feels super-unclear about what exactly is involved. Can HN folks who know more weigh in?

Hey, CipherStash founder here.

Our model is that data is encrypted in the application before being saved to the database. In order to encrypt, decrypt or query, you need to use the SDK (@cipherstash/stack). Connecting via psql, pgadmin etc, you'll only ever be able to see encrypted values (those tools don't know how to decrypt).

Proxy connects to the database and then you connect to the proxy (with psql or whatever). Proxy can now perform queries and decryptions on your behalf so that you can still access data if you need - hence "escape hatch".

The proxy authenticates using your credentials (or an access key) and interacts with the key management server.

Hope that helps!

Re: Searchable field-level encryption on Supabase with CipherStash

#12

Post by dandraper »

localhoster wrote: post #7

Looking at their website, reading through abit, and seeing the comments here. Guys, this website is entirely ai generated, which might indicate about their product some. Not saying that they are lieing or anything, but expect a wall of text that no one really read through, and expect to (pun intended) cipher out the details.

CipherStash founder here: I'll cop it about the website - we're a small team so we lean on AI for marketing copy but this is a reminder that we need to do better.

The tech is the result of 6 years of work. We're a team of 8 engineers and have been working on it full time thanks to VC funding.

I'm obviously biased but its legit tech. We've invested in making it fast, secure and able to support most common query patterns.

Our github repos might be better than our website but I'll certainly admit that our docs/marketing needs some work!

Checkout out: https://github.com/cipherstash/stack https://github.com/cipherstash/encrypt-query-language https://github.com/cipherstash/proxy

Re: Searchable field-level encryption on Supabase with CipherStash

#13

Post by dandraper »

maxrmk wrote: post #3

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?

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

Re: Searchable field-level encryption on Supabase with CipherStash

#14

Post by dandraper »

tekacs wrote: post #2

I came here to say that this is presumably ORE/OPE (order-revealing/preserving) encryption, not FHE, but... It is both remarkable and depressing how _little_ information is given, and how buried it is on the CipherStash website... _any_ information on what their security and/or threat model is, what is actually stored, how encryption and search works, or any trade-offs involved. Just to list a few pages that tell you…

Hey, CipherStash founder here: So we actually have 2 kinds of encryption: * standard encryption which can be decrypted (we call this "source" encryption) * what we call SEM: searchable encrypted metadata (cannot be decrypted)

Queries are performed by generating SEM which is "compared" to values in the table and the source encrypted values are returned to the caller (usually an application or agent) which does the actual decryption.

This is crucial because if you have a table of millions of rows, you don't want to decrypt every one to find the results. SEM works with built in postgres indexes (B-tree, GIN) so a query over millions of rows executes in literally milliseconds. Then the resultset (typically only 10s or 100s or rows) can is all that needs to be actually decrypted.

You're right that we use OPE and ORE. OPE is necessary on Supabase right now due to some limitations on their side but that's being addressed. ORE is more secure and almost as fast but requires "CREATE OPERATOR FAMILY" permissions in postgres to work.

We also use encrypted bloom filters and structured encryption (STE) for queries over JSON objects.

Re: Searchable field-level encryption on Supabase with CipherStash

#15

Post by MattPalmer1086 »

maxrmk wrote: post #3

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?

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.

Re: Searchable field-level encryption on Supabase with CipherStash

#16

Post by hsbauauvhabzb »

dandraper wrote: post #13
maxrmk wrote: post #3

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?

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 encr…

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.

Re: Searchable field-level encryption on Supabase with CipherStash

#17

Post by dandraper »

dandraper wrote: post #11
jph wrote: post #4

> Anywhere you need direct database access outside your application, CipherStash Proxy provides a secure escape hatch. This sounds like a back door. Is it? To me, the whole article feels super-unclear about what exactly is involved. Can HN folks who know more weigh in?

Hey, CipherStash founder here. Our model is that data is encrypted in the application before being saved to the database. In order to encrypt, decrypt or query, you need to use the SDK (@cipherstash/stack). Connecting via psql, pgadmin etc, you'll only ever be able to see encrypted values (those tools don't know how to decrypt). Proxy connects to the database and then you connect to the proxy (with psql or whatever).…

Also the proxy runs in your infra not ours (docker container).

Re: Searchable field-level encryption on Supabase with CipherStash

#18

Post by MikhailTal »

dandraper wrote: post #13
maxrmk wrote: post #3

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?

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 encr…

the OP asked why, you more described the how.

What is the benefit of all this?

Re: Searchable field-level encryption on Supabase with CipherStash

#20

Post by repeekad »

hsbauauvhabzb wrote: post #16
dandraper wrote: post #13

Earlier quoted context omitted.

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 encr…

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 ang…

Careful, they’ll take “gold plated compliance security” and use it in sales pitches
Post reply on HN