cipher.ink FAQ

Yes. There are no accounts, no ads and no paid tier. It's a small independent project with no tracking to pay for.

No. Your browser encrypts the message before it leaves your device, and the key never reaches our server, so all we hold is ciphertext. Even with full access to the database we couldn't read a message. What we can see is listed on the security page: sizes, times, the mode, and the passphrase hint if you wrote one.

Then the message is gone, for you and for us. The passphrase is the only thing that makes the key, and that's exactly what makes the scheme secure. Keep it somewhere safe or pick one you can remember. The passphrase generator makes memorable ones.

In passphrase mode the reader needs a passphrase that you pass along another way, so the link alone is useless. In secret-link mode there's no passphrase: the key rides in the link itself, after the #, so whoever has the whole link can open the message. Pick passphrase mode if others might see the link, and a secret link when convenience matters more. How it works has the details.

Not in the strict sense. It's client-side encryption with a shared secret: the server can't read the message, but there are no accounts or identities, so nothing proves who sent it or who opened it. This article explains the difference.

No. For a burn-after-reading message, the page the link loads doesn't contain the message. It's released only when a person presses Unseal and burn, and a scanner that just fetches the link gets the empty lock card. See how burn after reading works.

Exactly one of them gets it. The server ends the message in a single atomic step, only the request that wins receives the ciphertext, and the other is told it's gone.

Burned means someone opened a burn-after-reading message and it deleted itself. Destroyed means someone holding the message pressed Destroy it now. Expired means its time ran out. Nothing here means it never existed, or the address is wrong. In every case the server no longer has the message.

No. When a message ends, the server wipes its ciphertext at once and keeps only timestamps, which hold no content, for 90 days. If the reader still has the tab open, the message is still on their screen.

No. The hint is stored and shown in plain text on the lock screen to anyone with the link, and the page says so. Write one that helps you and nobody else, or leave it blank.

Yes. Keep the private read-receipt link, or find the message under My messages in the browser you sealed it from, and press Destroy it now. Anyone who has opened the message can destroy it too, since opening it gives them the same token.

The read-receipt page for your message shows when it was first opened and how many times. A read counts only after the message has been decrypted successfully, so link previews and scanners don't register. See read receipts without tracking.

Until the first of three things happens: it burns, someone destroys it, or its expiry passes. You choose the expiry: 10 minutes, 1 hour, 1 day, 1 week (the default), 30 days, or never. The default is one week.

No. Sealing uploads the sealed message and opening downloads it, so both ends need a connection. Nothing is sent while you write, though, and the page doesn't need a connection to keep what you've typed.

A message can run to about 700 KB of ciphertext, roughly 500 KB of text, and you can attach up to 10 files totaling 5 MB. The cap keeps the service small and cheap to run. For anything larger, put the files in an encrypted archive and send that.

Any type. Each file is encrypted separately, and its name, type and size are sealed inside the message, so the server sees only encrypted bytes. When someone reads the message, PNG, JPEG, GIF, WebP and AVIF images show inline. Every other type, SVG included, is a download and never opens in the page.

Your passphrase goes through 600,000 rounds of PBKDF2 to make the key, which takes a fraction of a second on most devices. The delay is deliberate, because it makes every guess at a passphrase cost the same. This article explains it, and the benchmark measures it on your device.

If the message isn't set to burn, anyone with the link can download its ciphertext and try passphrases against it offline, so strength matters. Five or six random words is a good choice, and the crack-time estimator shows how long guessing would take.

AES-256 in Galois/Counter Mode, through the browser's own Web Crypto API, with a 12 bytes (96 bits) random IV per message and a 128-bit authentication tag. Passphrase keys come from PBKDF2-HMAC-SHA256 with 600,000 iterations. AES-GCM, explained covers the cipher.

None of them. No cookies, no trackers, no analytics, no ads, and no requests to any other site. The browser enforces that last part through a Content-Security-Policy. The one script from another address is the feedback tab, from feedback.cipher.ink, a server I also run. Preferences such as the ink or paper theme stay in your browser's local storage and go nowhere.

In two places. The web host's access logs record the address, the time and the page for every request, outside the application. The application itself stores your address only as a salted hash, in hourly buckets, for two days, to limit how many messages one connection can seal in an hour.

Yes. The app is on GitHub at github.com/dustball/cipher.ink under the AGPL-3.0: the pages, the server, crypto.js, the tests and a spec of the message format. The articles, tools and puzzles aren't in it. Each release has a SHA256SUMS file, so you can check that what your browser loaded is what's published (Read the code shows how).

They still open with their original passphrase, through a separate, read-only path. They were sealed in a weaker format, so if one matters, copy its contents and seal it again. How they are still opened has the technical story.

Yes, and no website can prevent that. A reader can take a screenshot, photograph the screen or copy the text. Burn after reading limits the number of readers and how long the server holds the message, but it can't control what a reader does afterward.

Yes, on any current browser that supports the Web Crypto API, which covers all recent versions of Chrome, Edge, Firefox and Safari on phones and computers. On a phone, the lock controls move to a bar at the bottom of the screen.

There's no public API. The server's interface is internal and can change without notice. Because the encryption happens in the browser, a script would have to reproduce it, and the source on the code page shows exactly how.

Use the contact form and paste the message's address, only the part up to the #. That's enough to remove it, and it doesn't give us the key. We can't read a message, but we can end it.

AES-256 is believed to stay secure. The best known quantum attack on it, Grover's algorithm, would cut its strength to about 128 bits, which is still out of reach. The parts quantum computers threaten are public-key systems such as RSA and elliptic curves, and cipher.ink doesn't use those.

You shouldn't have to take our word for it, which is why the code is readable and the limits are written down. The honest edge is that you trust the server to send honest JavaScript, as with any web-based encryption tool. The security page lists that and the other limits without euphemism.

cipher.ink has been a small independent project since 2016, and it's run by B Klug, who also writes the articles. Write through the contact form or to support@cipher.ink. Neither is encrypted.