Tockermail
A way to send a password or a private note as a one-time link: it's encrypted in your own browser, and it erases itself the moment the recipient reads it.
- AES-256-GCM
- encryption runs in your browser, not on the server
- Zero-knowledge
- the server only ever stores scrambled text
- One open
- the first read deletes the stored copy, it isn't archived
The problem
Passwords, keys and private notes get handed over through chat, email and text, where they sit in searchable history forever, get forwarded, and quietly leak. There's no easy way to send one so it can be read exactly once and then genuinely disappears, especially when the person receiving it isn't technical and is on a phone.
What it does
You write a short message (a name, a subject, a note, small attachments) right on the page. It's encrypted on your device before anything is uploaded, and you get a link to share yourself, or Tockermail can email the link for you.
The recipient opens the link, reads the message once, and it's gone. The read view is laid out like an ordinary email (from, subject, body, attachments) with a copy button beside each secret, so a non-technical person can use it without instructions. If a link was already opened by someone else, the page says so plainly and advises rotating the credentials.
Signed-in users get more: a dashboard to label and withdraw messages that haven't been opened yet, longer expiry windows, encrypted reply threads, and for teams, links that require a signed-in member before they'll open. There's also a free, entirely in-browser password and passcode generator.
Key features
Encrypted in your browser
The service only ever receives scrambled text, never your plaintext or your key, so it can't read what you send even if it wanted to.
Opens once, then deleted
The first read destroys the stored copy, so the secret doesn't linger in a chat log or an inbox to be found later.
Optional passphrase
Add a second factor you send over a different channel, so a leaked link on its own still can't open the message.
Withdraw before it's read
A sender can pull back a message that hasn't been opened yet, and the recipient simply sees that it was withdrawn.
Team-gated links
A team can require a signed-in member before a message will open, checked before it burns, so a refused open never wastes the single read.
A read view anyone can use
The least technical recipient gets plain words, one clear button, a copy control for each secret, and guidance to rotate the credentials if the link was already opened.
Where it stands
Zero-knowledge holds fully for the share-the-link-yourself path. The optional email-delivery convenience passes the link's key through the server once in memory (never stored, and backed up by an added passphrase), a trade-off the product states openly rather than hides. Paid plans are modelled but not yet chargeable.
Under the hood: for the technically-minded
How it's built
Zero-knowledge here means the server is built so it can't read what you send. Your browser makes a random 256-bit key, folds in your optional passphrase, and stretches that into an encryption key with 600,000 rounds of PBKDF2, then encrypts the whole message locally. Only the scrambled text and the key-derivation salt are uploaded. The key itself lives in the part of the link after the '#', which browsers never send to any server.
At rest, the server wraps that already-encrypted blob in a second layer of AES-256-GCM under a separate server key, on a locked-down volume, so a stolen disk still yields nothing readable.
Opening is a deliberate action, not a page view. A single status-conditional update inside a transaction picks exactly one winner among simultaneous opens, and the stored blob is deleted in the same request, leaving only a marker that drives the already-opened page. Because opening is an explicit step, link-preview bots can't accidentally burn a message.
The hard problems
Keeping the key off the server
The decryption key must never reach the server, so it rides only in the link's fragment and the upload is limited to ciphertext plus the key-derivation parameters. The rule is enforced in the browser code and checked by tests that require a wrong key or wrong passphrase to fail.
Exactly-once destruction under a race
Two people opening the same link at the same instant must not both succeed. A transactional, status-conditional update guarantees a single winner, and the ciphertext is deleted in the very request that claims it.
The email-delivery trade-off, stated openly
Letting Tockermail email the link for you means the link's key passes through the server once, held in memory and never stored or logged. Rather than hide that, the product discloses it and recommends adding a passphrase so that path stays zero-trust.
Built with
- React Router 8
- Web Crypto (AES-256-GCM)
- PBKDF2
- better-sqlite3
- WebAuthn / passkeys
Building something in this space?
Work with us →