The security model
Zero-knowledge by architecture. The server stores ciphertext, wrapped keys, public keys, and metadata. It holds no key that decrypts any of it.
If you read nothing else on this page
Section titled “If you read nothing else on this page”A complete breach of our server and database gives an attacker every encrypted payload, every wrapped key, every public key, and the metadata: account emails, project and environment names and their order, payload sizes, version counts, and when things were read.
It does not give them a single secret value, because nothing on that machine can decrypt one.
Everything else in this section is a refinement of that paragraph — including the list of things we do not defend, which is longer than this page.
The boundary
Section titled “The boundary”Trust boundary
The server is a dumb pipe and a store. It can be fully compromised and an attacker still gets no usable secret, because it never holds a key that decrypts anything.
Why “can’t” rather than “won’t”
Section titled “Why “can’t” rather than “won’t””Three structural properties, none of which is a promise about behaviour:
The server does not link the code that could decrypt. It depends on the wire-format crate only, never on the crypto crate — and a continuous-integration check fails the build if that dependency edge is ever added. There is no code path from a stored blob to plaintext, because the code that knows how to do it is not in the binary.
Keys derive from two factors, one of which the server has never seen. Your master password combines with a Secret Key generated on your device, through Argon2id in keyed mode. Server-side data is therefore unbrute-forceable even against a weak password: the attacker is missing 32 bytes of CSPRNG output that were never transmitted.
Authentication is separate from decryption. An API token proves who you are and authorises downloading ciphertext. It decrypts nothing. An attacker holding every session token we have ever issued gets encrypted blobs.
The rest of this section
Section titled “The rest of this section”| Page | What’s in it |
|---|---|
| Key hierarchy | From your password down to a decrypted secret, diagrammed |
| Cryptography | The exact constructions, their parameters, and the test that pins each one |
| Security invariants | The eight rules the product is built to, verbatim |
| What the server refuses to do | A short list, and why each item is structural |
| What we do and do not defend | The honest one. Three tiers, nothing omitted |
| Telemetry and privacy | Zero telemetry, and exactly what metadata is visible |
| Report a vulnerability | Where to send it and what happens next |
What we have not earned yet
Section titled “What we have not earned yet”- No third-party cryptographic audit. On the roadmap, not started.
- No SOC 2. Same.
- The client source is not public. Publishing it is on the roadmap, and the reason it matters is that it is the only way to verify any of this rather than take our word for it. Until then these pages are the claim — written precisely enough to be falsified later, which is the most we can honestly offer.
If that is not enough for your situation, it should not be. See when not to use Cendarum.