Zero-knowledge is the gold standard of privacy architecture. It means a service provider can process and store your data without ever being able to read it. Here's exactly how CipherOnce achieves this — and how you can verify it.
The term "zero-knowledge" is frequently misused in marketing. A service that encrypts your data on their server using their own keys is not zero-knowledge — it's standard encryption with a trusted intermediary. True zero-knowledge means the service has no mathematical capability to decrypt your data, regardless of intent.
CipherOnce achieves this through a simple but powerful architectural principle: the encryption key is never transmitted to our servers. It is generated client-side, used client-side, and shared exclusively via the URL fragment — a component of URLs that browsers exclude from HTTP requests by specification.
Zero-knowledge is not a feature. It is an architectural constraint that makes reading your data impossible, not just against policy.
Key Generation
window.crypto.subtle.generateKey() produces a 256-bit AES-GCM key. This operation is local, hardware-accelerated, and produces cryptographically random output.
Encryption
window.crypto.subtle.encrypt() transforms your plaintext into ciphertext using the generated key and a random IV. The operation is performed entirely within the browser sandbox.
Key Export & URL Embedding
The key is exported as a base64 string and appended to the share URL as the fragment (#key). The fragment is never included in HTTP requests to our servers — this is RFC 3986 specification behavior, not a feature we implement.
Server Storage
Our server stores: (a) the ciphertext, (b) the IV, (c) the expiry, (d) the view counter. No key. No plaintext. No user identity required.
Decryption
The recipient's browser parses the URL fragment, fetches the ciphertext from our API, and calls window.crypto.subtle.decrypt(). The server processes a fetch request and returns encrypted bytes — it has no visibility into the key or plaintext.
We cannot be compelled: Law enforcement requests, court orders, and government demands for your secret content cannot be fulfilled — because we do not possess decryptable data. This is structural, not a policy we can be pressured to override.
Breaches become near-worthless: A successful database breach yields ciphertext encrypted with keys we don't have. The stolen data has no value to an attacker without the URLs, which were shared privately between sender and recipient.
Insider threats are neutralized: No CipherOnce employee, engineer, or DBA can access your secrets. The data we store is mathematically indecipherable without keys we never possessed.
Verifiable, not trustable: Our encryption implementation is open source. You can read the exact code that runs in your browser, confirm that keys are generated locally, and verify that only ciphertext is transmitted. Trust through transparency.
Open your browser's developer tools and navigate to the Network tab. Create a secret on CipherOnce. Examine every network request made during the creation process. You will observe that the request payload contains an encrypted blob — not your plaintext. You will observe that the URL fragment is never transmitted. You will find no outbound request containing your decryption key.
This is the difference between a privacy promise and privacy architecture: one requires trust, the other requires only verification.
What you'll see in DevTools network tab
POST /api/secrets
Body: { "ciphertext": "U2FsdGVkX1...", "iv": "aGVsbG8...", "expires_at": "..." }
# ← Key never appears in any request