CachetSecurity and transparency
What Cachet can promise, what it can’t, and how you can check for yourself. We would rather be clear about the limits than overpromise.
In one sentence
Each message is encrypted on your device with its own random key. The key is kept on our server and wiped when it expires. Until then, anyone holding the sealed text can open it; after that, nobody can, us included.
What the server keeps
| Kept | Why |
|---|---|
| Key ID | A random number, matching the one written in the sealed text |
| Key | 32 random bytes. Deleted when it expires, or as soon as a read-once message is opened |
| Expiry time, read count, read limit | For the countdown, “opened N times”, and read-once |
| Never kept, never seen | Why |
|---|---|
| Your message, plain or sealed | Encryption and decryption happen on your device or in your browser; the sealed text only travels through your chats |
| Access passwords | Used only in calculations on your device, never sent |
| Account, phone number, email | Cachet needs no sign-up |
| Access logs | The key API keeps no access log; this site has no analytics and loads nothing from third parties |
The exception: server-side encryption. For developers’ convenience we also offer
/v1/seal and /v1/open, where the server encrypts or decrypts for you and so briefly handles the plaintext in memory (never stored or logged). This website and the Cachet keyboard do not use them. See the API.
What Cachet protects against
- Any reading after expiry. Exported chat history, backups, archived screenshots, someone going through your phone: once the key has expired, the sealed text can’t be turned back.
- Someone with only the server’s data. The server has random keys but no sealed texts. The database alone opens nothing.
- Anyone without the password. A message with an access password can’t be opened without it, even by someone holding both the sealed text and the server’s key.
- Quiet peeking. Every open is counted, and the reader sees “opened N times”. A read-once message opens a single time: if someone gets there first, you’ll know.
What it can’t protect against
- Anyone who has the sealed text before it expires. That is the price of “anyone can open it”: if a chat platform or someone else gets the text in time, they can open it too. For sensitive content, set an access password and share it another way (in person, by phone).
- A reader who saves the message. Expiry stops later reading; it can’t stop a screenshot or a copy made while it was open.
- A compromised device. If your phone or computer, or the other person’s, is controlled by malware, no encryption tool can help.
- Our server’s keys stolen before expiry, together with the sealed text. That takes breaking into both our server and your chats.
Check it yourself
- The code this site runs: sdk/cachet.js is the complete, unminified implementation. Open your browser’s developer tools, Network tab: encrypting sends one request to the server (asking for a key), and it carries none of your content.
- An open protocol: every byte of a sealed message is described in the protocol, with test vectors. The Android, iOS, server and web implementations are checked byte for byte against the same vectors.
- Standard cryptography: AES-256-GCM, HKDF-SHA256, PBKDF2-SHA256 (100,000 iterations). In the browser it uses the independently audited open-source libraries noble-ciphers and noble-hashes.
What we’ll do next
- HTTPS everywhere, with HSTS and a strict Content Security Policy.
- Open-source the keyboard and server code, so anyone can inspect and build them.
- Let companies run their own key server and keep the keys themselves.
- Commission an independent security audit and publish the report.
Contact
Found a security problem? Email 3294009901@qq.com; we’ll fix it as fast as we can and credit you. How we handle data is in the Privacy Policy.