Zero-knowledge
Secrecy is a zero-knowledge service: it stores and moves your users' data without ever being able to read it. The data is encrypted on the device, by the SDK, before it is sent, and the keys that open it never reach the Secrecy servers in a readable form: Secrecy only stores them locked, and cannot unlock them. What reaches the servers is ciphertext, and nothing else.
What it changes for your application
In a typical service, encryption happens on the provider's side: your application sends readable data, and the provider encrypts it at rest with keys it controls. With Secrecy, that step moves into your application, inside the SDK.
| Typical cloud / mail API | With Secrecy | |
|---|---|---|
| Where data is encrypted | On the provider servers, after upload | On the device, by the SDK, before upload |
| Who holds the keys | The provider | The user devices only — Secrecy stores them locked |
| What the API receives | Readable data | Ciphertext |
| What a server breach exposes | Readable data | Ciphertext |
| Who can process the content | The provider, server side | Your application, after decryption on the device |
What it means in code
You never handle encryption yourself. The client returned by the sign-in holds the keys of the user, and encrypts and decrypts around every call: you give plain data to secrecyClient.cloud and secrecyClient.mail, and you get plain data back. How this works under the hood is described in how data is encrypted.
A few consequences follow from the model:
- No client, no decryption. Reading encrypted data always needs a client signed in as a user who was given access. Your backend, or Secrecy, cannot read it on the user's behalf.
- Content is processed on the device. Secrecy cannot search, index or transform the content it stores. Any such processing happens in your application, after decryption.
- Sharing is part of the encryption. Giving someone access means making the data readable for them, so every sharing model is also a way of handing over a key.
What stays readable
Zero-knowledge covers the content: files and their names, mail subjects, bodies and attachments, anonymous submissions. What the service needs to store and route that content is not encrypted: who shares with whom, sizes, dates, and the rights granted on each item.
When a user reports a file, the SDK deliberately hands the key of that file to Secrecy so it can be moderated. This only happens on an explicit report, for the reported file only.