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

41–50 of 54 posts

Re: Searchable field-level encryption on Supabase with CipherStash

#41

Post by dandraper »

cvwright wrote: post #39
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…

Don’t use deterministic encryption unless your data is already highly random. Any adversary who knows the distribution of the plaintext data can guess what your encrypted values are, with accuracy that improves as your sample size increases. There were a bunch of papers on this 10-12 years ago. (Full disclosure: I was an author on some of them.)

Yep, we’ve read the papers. Naveed et al and Grubbs et al primarily.

Re: Searchable field-level encryption on Supabase with CipherStash

#42

Post by dandraper »

nicce wrote: post #9
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?

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.

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?

Re: Searchable field-level encryption on Supabase with CipherStash

#43

Post by dandraper »

Thanks for all the comments.

CipherStash isn't something that we just threw together on a weekend. We've spent years developing it. I've personally invested almost every waking moment for the last 6 years working on this (and the prior 2 preparing to quit my job so I could work on it full time).

I get that it seems like snake oil to some. But that's just because we don't do a good enough job of explaining what we've created. We're working on that - we're engineers, not marketers.

There have been prior attempts at making tech like this work, and maybe because those approaches were limited, its tainted how folks see encryption tech. We've studied many of the previous attempts and invested in the engineering required to overcome the problems.

Key management - we made a 2 party key system that is faster and has a better security model than AWS KMS alone. Not because we thought it was fun, not on a whim but because it was the only way to solve the real security challenges we faced when it comes to protecting data.

Searchable encryption - that is less secure than homomorphic encryption but FAST. Like under a few milliseconds for most queries (homomorphic would take literally minutes or worse). And a whole lot better than no encryption at all. It uses a key per value.

Encrypt query language - a framework that makes searchable encryption work in standard postgres. No exotic index schemes, no custom builds. Just SQL functions.

Typescript and Rust libraries to make this _almost_ drop-in for Prisma Next, supabase-js and Drizzle.

Identity integrations with Supabase, Clerk, Auth0, and Okta.

A postgres proxy that automatically encrypts and decrypts data for authorized requests - for when using the SDK isn't possible/convenient.

And an audit system that records every access and can send data to anything you can connect to AWS firehose or an S3 bucket.

This is real and IMHO is exceptional engineering...anyone know a great technical marketer?!

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

Re: Searchable field-level encryption on Supabase with CipherStash

#44

Post by sigseg1v »

dandraper wrote: post #40
sigseg1v wrote: post #38

Earlier quoted context omitted.

Something here seems to not fit together to me on the assumptions this is based on, because you say > We're explicitly not claiming to defend against an attacker who fully owns your running application with valid credentials. and dandraper says: > I was CTO [...] and the engineers all had access to patient data. They needed DB access [...] but not access to the sensitive values > [...] > CipherStash solves the follow…

This doesn’t have anything to do with being able to change the code. Devs can code and change things as they need. The database is also the same as it always is. What CipherStash does is let you specify specific columns that you want to encrypt. The application (via our SDK), encrypts values for that field before it’s saved and optionally decrypts it again when it’s read. Decryption is performed when the user provide…

It's still not piecing together 100% for me, sorry I'm not trying to be obtuse or anything.

So maybe let me simplify my question: If I set up both a copy of a database with values encrypted by CipherStash, and an application server connected to it, and the application server has enough access to do queries on sensitive data (eg "WHERE sensitiveField = ?", pretend it needs that for a migration), and a developer has root access on the application box while it's running, and a gdb session connected to the app, can they see any sensitive data or no?

If they can't, then that's genuinely cool, and I probably need to look into the workings a bit more!

Re: Searchable field-level encryption on Supabase with CipherStash

#45

Post by dandraper »

sigseg1v wrote: post #44
dandraper wrote: post #40

Earlier quoted context omitted.

This doesn’t have anything to do with being able to change the code. Devs can code and change things as they need. The database is also the same as it always is. What CipherStash does is let you specify specific columns that you want to encrypt. The application (via our SDK), encrypts values for that field before it’s saved and optionally decrypts it again when it’s read. Decryption is performed when the user provide…

It's still not piecing together 100% for me, sorry I'm not trying to be obtuse or anything. So maybe let me simplify my question: If I set up both a copy of a database with values encrypted by CipherStash, and an application server connected to it, and the application server has enough access to do queries on sensitive data (eg "WHERE sensitiveField = ?", pretend it needs that for a migration), and a developer has ro…

Applications do not have access - individual authenticated users have access. A user must be authenticated & authorised in order to be able to create encrypted query terms. This is enforced by CipherStash's key server (ZeroKMS), not the application.

Having a copy of the production database and a local copy of the application and a debugger is insufficient to be able to encrypt/decrypt any values or run any queries involving encrypted search terms: you'd still need to authenticate with ZeroKMS.

Having root access to a production server running an application is a different matter because you'd have access to the entire address space of the app that real authenticated users are interacting with. A sufficiently motivated adversary would be able to intercept auth tokens allowing impersonation of an authorised user.

The application server process is a trust boundary in this model and thus requires appropriate access controls.

To address this last point, we now support decryption in edge workers like Cloudflare or Supabase Edge Functions. We also have browser-based encryption/decryption in the works. Both of these approaches mean data is never decrypted in the app, not even in production.

Re: Searchable field-level encryption on Supabase with CipherStash

#46

Post by DANmode »

dandraper wrote: post #12
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 patter…

> I'll certainly admit that our docs/marketing needs some work!

Any chance you’re hiring for a related role? Technical marketing and technical documentation are my jam!

Re: Searchable field-level encryption on Supabase with CipherStash

#47

Post by dandraper »

DANmode wrote: post #46
dandraper wrote: post #12

Earlier quoted context omitted.

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

> I'll certainly admit that our docs/marketing needs some work! Any chance you’re hiring for a related role? Technical marketing and technical documentation are my jam!

Let’s chat dan@cipherstash.com

Re: Searchable field-level encryption on Supabase with CipherStash

#48

Post by catmanjan »

dandraper wrote: post #30
catmanjan wrote: post #29

Earlier quoted context omitted.

So the audit log contains an ID for a key which could decrypt a value - does the audit log also contain the encrypted value itself? If not, how do you go from the audit log back to the original value in 1?

No, not by default. You could but as you said, that would be a A LOT of data. It depends on your setup. If you're using Supabase, one way is to send the logs to Clickhouse and use the Clickhouse partner integration to query the audit logs and join it to the actual data. Keeping only the ids in the audit log means you need to stitch the data together later. This means you don't accidentally leak data via your audit tr…

Ok Im having trouble reconciling this comment

> SQL query auditing is great for knowing what queries were run but it doesn't tell you what data was actually returned

With what you’re saying - sounds like cipher doesnt tell you what data was actually returned either - it will only tell you if the user could have received a decrypted version of the data right?

Re: Searchable field-level encryption on Supabase with CipherStash

#49

Post by catmanjan »

dandraper wrote: post #45
sigseg1v wrote: post #44

Earlier quoted context omitted.

It's still not piecing together 100% for me, sorry I'm not trying to be obtuse or anything. So maybe let me simplify my question: If I set up both a copy of a database with values encrypted by CipherStash, and an application server connected to it, and the application server has enough access to do queries on sensitive data (eg "WHERE sensitiveField = ?", pretend it needs that for a migration), and a developer has ro…

Applications do not have access - individual authenticated users have access. A user must be authenticated & authorised in order to be able to create encrypted query terms. This is enforced by CipherStash's key server (ZeroKMS), not the application. Having a copy of the production database and a local copy of the application and a debugger is insufficient to be able to encrypt/decrypt any values or run any queries in…

Your last point is very cool, this seems like a slept on technology

Re: Searchable field-level encryption on Supabase with CipherStash

#50

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?

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.

Post reply on HN