Comment by tekacs | Hacker News Reader

Comment by tekacs | Hacker News Reader

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

You basically reverse-engineered it correctly. I've written up the full threat model, components and per-index leakage in one place here: https://news.ycombinator.com/item?id=48967481

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.

Reply on news.ycombinator.com