Searchable field-level encryption on Supabase with CipherStash
1–10 of 54 posts
Re: Searchable field-level encryption on Supabase with CipherStash
#2I 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 next to nothing:
https://cipherstash.com/docs/stack/reference/what-is-ciphers...
https://cipherstash.com/docs/stack/cipherstash/encryption/se...
https://cipherstash.com/docs/stack/cipherstash/encryption
I eventually found:
https://cipherstash.com/docs/stack/reference/security-archit...
Which... it sounds like 'searched without being decrypted' means... it encrypts your query against their fast KMS and uses that to compare against indexes that were also encrypted with the same KMS? And ORE/OPE is an optional mode when you want range support.
Re: Searchable field-level encryption on Supabase with CipherStash
#3I’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?
Re: Searchable field-level encryption on Supabase with CipherStash
#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?
Re: Searchable field-level encryption on Supabase with CipherStash
#5I’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?
My thoughts as well. Seems like security theater.
Re: Searchable field-level encryption on Supabase with CipherStash
#6I’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?
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.
Re: Searchable field-level encryption on Supabase with CipherStash
#7Looking 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.
Re: Searchable field-level encryption on Supabase with CipherStash
#8We worked with the CipherStash team to build a Prisma Next extension that provides full type safety for their additional query shapes, and a fully managed experience for applying schema changes. It was a great experience working with the team, and we were particularly excited about this, as it helped us prove out the new extensibility mechanisms we have been working so hard for in Prisma Next.
Docs here: https://cipherstash.com/docs/stack/cipherstash/encryption/pr...
And a mention in our April update on Prisma Next: https://www.prisma.io/blog/prisma-next-roadmap-april-milesto...
If you want to give CipherStash on Supabase a try, using Prisma Next is the smoothest experience.
Re: Searchable field-level encryption on Supabase with CipherStash
#9I’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.
Re: Searchable field-level encryption on Supabase with CipherStash
#10I’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?
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.
A lot is allowed: https://cipherstash.com/docs/stack/cipherstash/encryption/se...