CipherStash QX, where your encrypted data is stored and queried, runs in a fully-managed environment close to your app. The CipherStash QX client, where all encryption and decryption takes place, runs in your application, meaning that your data is always under your control. CipherStash QX (and our infrastructure in AWS) never sees any of your data in the clear.
CipherStash QX works with both NoSQL and SQL databases.
CipherStash QX integrates at the application layer, and doesn’t rely on any database features for queryable encryption.
For more information on why we chose gRPC, see our blog post on the topic.
Why doesn’t CipherStash QX use the standard AWS environment variables (like
We do this precisely because we don’t want to conflict with the standard AWS environment variables.
For example, consider an application that uses resources in AWS (say, it stores uploads in S3).
As a way of segmenting and limiting access permissions, you would supply two sets of credentials to the application — one for accessing KMS, the other for accessing S3.
If CipherStash QX uses the standard AWS environment variables for KMS access, that application can’t also use the standard environment variables for S3 access.
CipherStash QX is capable of returning a count of records that match a query.
Additional aggregations such as min, max, mean, and sum are also planned for future support.
These index types give you control over what text is indexed, and how the text is tokenized and transformed before being indexed.
By default query results do not have a stable sorting order. However, you can sort results on any field that has a range index.
See the library-specific docs for details on sorting query results:
Yes. We believe that encryption should be open source and developed transparently. Scrutiny breeds trust.
All CipherStash QX client code, including our cryptographic code, can be found on GitHub: