dandraper

6 ms·

1.
by dandraper 2mo ago
Sorry I was imprecise. Query logging would tell you what queries were executed. E.g the following would tell you that 10 user records were returned with name and email but not which users. SELECT name, email FROM users LIMIT 10; CipherSta
2.
by dandraper 2mo ago
> What does the risk profile look like in a full leak of the encrypted database? We actually have a number of different schemes which trade leakage for performance/storage overhead/compatibility. Each one has its own type in Po
3.
by 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
4.
by dandraper 2mo ago
Let’s chat dan@cipherstash.com
5.
by dandraper 2mo ago
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), no
6.
by dandraper 2mo ago
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
7.
by 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?
8.
by dandraper 2mo ago
Yep, we’ve read the papers. Naveed et al and Grubbs et al primarily.
9.
by dandraper 2mo ago
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 enc
10.
by dandraper 2mo ago
No, to derive a key you need a client key (controlled by the app) and key-seeds for each value which can only be retrieved from the key server with a valid JWT. The JWT is time bound (15 mins). Now, if an attacker could gain access to the c
11.
by dandraper 2mo ago
Encrypted*.
12.
by dandraper 2mo ago
It is indeed the case.
13.
by dandraper 2mo ago
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 l
14.
by dandraper 2mo ago
Not just each column, each value . The answer to your question is yes. Explanation: The identifier is actually for the key that encrypts the value (1 unique key per value). 1. When the value is encrypted for the first time, it gets an ID.
15.
by dandraper 2mo ago
CipherStash - specifically the key service. There is a lot of data for sure but we only record an identifier for each value and (optionally) the user ID. It compresses well.
16.
by dandraper 2mo ago
If we do, I'll be sure to attribute it to this thread :p
17.
by 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 traditi
18.
by dandraper 2mo ago
I've replied above
19.
by dandraper 2mo ago
Searchable encryption means you can have encryption and queries (from apps etc) still work for authorized users. This is all started when I was the CTO of a health-tech and the engineers all had access to patient data. They needed DB access
20.
by dandraper 2mo ago
Also the proxy runs in your infra not ours (docker container).
21.
by dandraper 2mo ago
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) Quer
22.
by 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 ciphert
23.
by dandraper 2mo ago
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 e
24.
by dandraper 2mo ago
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
25.
Searchable field-level encryption on Supabase with CipherStash(supabase.com)
48 points by dandraper 2mo ago|52 comments
26.
Show HN: CipherStash Stack – Data Level Access Control in TS/JS(cipherstash.com)
17 points by dandraper 4mo ago|0 comments
27.
by dandraper 1y ago
CipherStash founder here: FHE isn't the only option here. Specialized searchable encryption schemes exist and are much faster than FHE. Different flavours can be combined to create a comprehensive search system which is very close to
28.
Show HN: Rewriting SQL on the Fly in CipherStash Proxy(cipherstash.com)
4 points by dandraper 1y ago|0 comments
29.
Show HN: Searchable encryption, SQL proxy for Postgres(cipherstash.com)
10 points by dandraper 1y ago|0 comments
30.
Verifying Rust Zeroize with Assembly Including Portable SIMD(cipherstash.com)
1 points by dandraper 1y ago|0 comments

More ›