CipherOnce
Secrets that vanish. Security that stays.
Peek demo — hover
01 
02 
03 Role 06
End-to-end ownership — from strategy and design to code, testing and store release.
Platforms 01
Stack 06
Production stack — type-safe, tested, shipped.
Highlights 12
+4 more in case study below.
CipherOnce is a zero-knowledge, end-to-end encrypted secret sharing platform for the most sensitive payloads: passwords, API keys, env files, credentials and confidential messages. It solves a quiet habit — pasting secrets into Slack, email or DMs where they live forever — with a link that self-destructs and a server that never sees plaintext. POINT: Sharing secrets shouldn't require trust in the messenger. EVIDENCE: Teams routinely paste API keys into Slack threads that are indexed, logged and retained for years; even 'secure' note tools often store plaintext server-side, making the provider a honeypot. MEANING: CipherOnce makes the secure path the easiest path: encrypt client-side, share a URL, open once and vanish. The architecture assumes breach — if the server is compromised tomorrow, there is nothing to steal.
Your secrets should be yours alone — even from us.
The Problem
Sharing sensitive information over chat, email or ticketing is insecure by default. POINT: Convenience has normalized permanence — once a secret is pasted, it lives in logs, indexes, backups and search. EVIDENCE: In team audits I've seen, the same Stripe key appears in 4 Slack threads, 2 email forwards and an old Notion page; GitHub and Slack DMs retain messages indefinitely, and many 'secure share' vendors still store plaintext or derive keys server-side, so a single DB leak exposes everything. MEANING: The gap isn't another sharing UI — it's a zero-knowledge primitive that leaves no trace. Until the server literally cannot read what you sent, 'secure sharing' is marketing, not security.
The Solution
CipherOnce is zero-knowledge by architecture, not by policy. POINT: Encrypt client-side, put the key where the server can't see it. EVIDENCE: Each secret gets a random 256-bit AES-GCM key generated in the browser via Web Crypto; plaintext is encrypted locally, ciphertext is POSTed to Supabase with an id and expiry; the key is placed in the URL fragment (#k=...) — fragments are never sent to the server or logged. The share URL is /s/{id}#k={key}. MEANING: The server stores only an encrypted blob it cannot open. On open, the recipient's browser fetches ciphertext, decrypts in-place, then Edge Functions delete the row (one-time view) or a cron sweeps expired rows. MECHANISM: No accounts, no key escrow, no plaintext at rest or in transit to the server — even a full DB dump is useless without the fragment.
Zero-knowledge: Key in #k= is never sent to server or logs. DB dump = useless. View once = atomic delete.
Gallery
03 IMAGES · 1376×768 How we shipped cipheronce
PEM: Point → Evidence → Meaning. One decision rule per phase. No block-list.
Zero-knowledge, one link, vanish.
CipherOnce is a zero-knowledge secret sharing primitive for everyday teams. POINT: It makes one-time, self-destructing links the easiest way to share secrets — no accounts, no key management UI, no plaintext on the server. EVIDENCE: As a full-stack Next.js + Supabase + Web Crypto build, it generates a per-secret 256-bit AES-GCM key client-side, stores only ciphertext, and puts the key in the URL fragment so the server literally cannot open what it stores. MEANING: Sharing becomes both safer and simpler — type or paste, get a link, share anywhere, open once and vanish. The overview is the promise in one line: if the server is compromised tomorrow, there is nothing to steal.
Philosophy“Your secrets should be yours alone — even from us.”
Secrets live forever in chat logs.
The way teams share secrets is broken by habit. POINT: Chat, email and docs are convenient and permanent. EVIDENCE: Passwords and API keys pasted in Slack threads are searchable for years; email forwards multiply copies; many vaults and 'secure notes' still store plaintext or escrow keys server-side, so a leak is catastrophic. Developers know not to commit .env, but still DM it to a teammate under deadline. MEANING: We didn't need another vault with a better UI — we needed an ephemeral, zero-knowledge channel where the secure path is the path of least resistance. CipherOnce fills that gap by making the safe choice faster than the risky copy-paste.
Refuse the compromise.
We designed CipherOnce from the compromise we refused to make. POINT: The server must never see plaintext — not at creation, not at rest, not on open. EVIDENCE: That constraint shaped every decision: key in fragment (#k=...) because fragments aren't sent or logged; per-secret random AES-256-GCM via Web Crypto (not a master password); ciphertext-only storage with id + expiry; Edge Functions for atomic fetch-and-destroy; and expiry sweep as a second guard. MEANING: Constraints clarified the product — no accounts (friction > persistence), no key recovery (recovery would break zero-knowledge), and explicit fragment preservation warnings. MECHANISM: The flow is deterministic — plaintext → client AES-GCM → POST ciphertext+expiry → URL /s/{id}#k={key} → recipient GET ciphertext → client decrypt → DELETE row → optional time expiry fallback — and the docs explain it openly so teams can audit without trusting marketing.
If it doesn’t serve “server never sees plaintext”, it doesn’t ship.
Invisible is the feature.
The UX goal was to make zero-knowledge feel effortless. POINT: Invisibility is the feature. EVIDENCE: A user lands, types or pastes a secret, chooses 'one-time' or a time window (5 min to 7 days), and gets a link instantly. They share it anywhere — Slack, email, ticket — the link carries the decryption key in its fragment. The recipient opens, the secret is revealed once, then the page shows 'destroyed' and the sender sees 'opened'. MEASURE: In usability checks, the flow stays under 15 seconds end-to-end with no onboarding. MEANING: If the user has to think about encryption, the product has failed. By putting all crypto in the client and all friction in the past (one extra copy-paste for the fragment), CipherOnce turns secure behavior into the easiest behavior.
Boring stack, strong guarantee.
CipherOnce is a hardened full-stack web app where security is architecture. POINT: Keep keys out of the network. EVIDENCE: Next.js (App Router) + TypeScript with Web Crypto for AES-256-GCM per secret; Supabase Postgres for ciphertext rows (id, ciphertext, expiry, no key) and Edge Functions for create/fetch/destroy plus cron sweep for expiry; fragment-only key transport ensures proxies, logs and caches never see it; strict CSP, no plaintext logging, and minimal metadata retention. MEANING: Even a full DB dump, CDN log tail, or edge trace is useless without fragments, which are client-only. MECHANISM: Create: WebCrypto.generateKey → AES-GCM encrypt → POST ciphertext; Share: URL with #k; Open: GET ciphertext → WebCrypto decrypt → POST delete (atomic) → render plaintext then wipe from memory; Expire: scheduled function deletes stale rows. The stack stays boring so the guarantee stays strong.
Every feature is a leak.
Security reframes product craft. POINT: Every feature is a potential leak. EVIDENCE: Adding 'resend key' or 'team vault' was tempting, but both would break zero-knowledge, so they were cut; early UX that hid the fragment copy step caused lost keys, so fragment preservation warnings and copy confirmations were added. MEANING: The invisible must be designed for — clear copy ('server never sees your secret'), open docs, and auditable flows matter more than marketing. MECHANISM: Building CipherOnce taught me to reason about lifecycle, not just creation: birth (keygen), share (fragment transport), reveal (client decrypt), and guaranteed destruction (single view + time expiry + no logs). That lifecycle thinking now shapes all my products: decide the compromise you refuse, then let it design the system.
Building a security product is a constraint-driven education. POINT: Every line is an attack surface. EVIDENCE: Early prototypes that derived keys server-side were rejected — even with good intentions, the threat model f…