cinderpaste

The security model

cinderpaste is zero-knowledge: the server stores ciphertext and nothing else.

Encryption happens in your browser

Before anything leaves your device, your text is encrypted with AES-256-GCM using the Web Crypto API. The server only ever receives the ciphertext, a random initialization vector, and — for password pastes — a random salt. It never sees your plaintext.

Where the key lives

For a keyless share, a random 256-bit key is generated in your browser and placed in the URL after the # fragment (e.g. /p/abc123#k=…). Browsers never transmit the fragment to the server, so the key stays with whoever holds the link.

Password pastes

When you set a passphrase, the key is derived from it with PBKDF2-SHA256 over 600,000 iterations and a 16-byte random salt. The passphrase itself is never sent anywhere — share it out of band.

Burn after reading

A burn paste is fetched and deleted in a single atomic database transaction, so it can be read exactly once. The second visit finds nothing.

No accounts, no logs, no tracking

There are no cookies, no analytics, and no account system. Rate limiting uses a keyed hash of your IP — the raw address is never stored. Expired pastes are purged automatically.

What we can and can't do

Because the server holds no keys, we cannot read, recover, or hand over your content. If you lose the link (or passphrase), the paste is gone for good.