Protect sensitive data even if the database is breached

Refined Question

If an attacker obtains full read access to our database — through SQL injection, a stolen superuser credential, or a leaked backup — what do they actually get? How do we make the answer "ciphertext" rather than "everything"?

Why This Matters

The database is the highest-value target in the stack, and full-database compromise is the worst-case scenario behind most breach headlines. Transparent disk encryption doesn't help here: the database happily decrypts everything for anyone who can query it.

Why CipherStash

CipherStash encrypts each sensitive value with its own key before it reaches Postgres, and ZeroKMS derives keys per request rather than storing them. The database never holds the means of decryption, so compromising it — or its replicas and backups — yields ciphertext.

This allows:

• Full-database dumps and stolen backups to contain no usable sensitive data
• SQL injection to read ciphertext instead of customer records
• Key compromise at rest to be structurally impossible — keys aren't stored
• Breach disclosure scope to be limited to what was actually decrypted

Key Differentiators

• Per-value keys via ZeroKMS — keys are derived on demand, never stored
• Application-layer encryption — data is protected before it reaches the database
• Searchable encryption — equality, range, and free-text queries over encrypted Postgres fields, with standard indexes
• Cryptographic auditability — a verifiable record of who decrypted what, and when
• No re-platforming — works over the Postgres you already run