We don't need to search encrypted data. Why would we need you?
- Date
- By
- CipherStash Team
Most teams don't, and search is optional per column. Search exists so encryption does not break the queries you already run. What CipherStash is for is data-level access control: every value under its own key, and the decision to derive that key bound to an identity. That works with search switched off everywhere.
Take the strongest version of field-level encryption: one key per value, so a leaked key exposes one thing, and an access decision on every decrypt. Build that on AES plus a cloud KMS and you hit two walls.
The first is the key service. One key per value means one KMS operation per value, which is slow and expensive, so teams cache data keys, and the cache quietly turns per-value keys back into a shared key.
The second is the database. Ciphertext under a random key per value is opaque. WHERE email = ? stops working, and so do sorting, ranges and text search. Teams respond by leaving the fields that need queries in plaintext.
ZeroKMS is the answer to the first wall. It batches key derivation, so a page of rows is one request, up to 500 values by default. Searchable encryption is the answer to the second, and only for the columns that need it.
What you get with search off
With per-value keys and an identity in the key derivation, "can this value become plaintext for this caller" is answered in the cryptography rather than in application code. That is what we mean by data-level access control, and none of it depends on search. Turn search off on every column and you still have per-value keys, identity-bound decryption, and free decryption.
It matters more each year as the set of things reading your database grows: services, integrations, and now agents that hold credentials and follow instructions.