Cryptographic architecture
What Pastepile's encryption does, what it protects against, and in equal detail what it does not. Nothing here claims the system is unbreakable, because it is not. Encryption delivered through a browser has a hard ceiling, and it is stated plainly below.
For the shorter version of what we store, see the security page.
Primitives
Everything uses the browser's built-in Web Crypto API. There is no hand-written cipher and no third-party cryptography library anywhere in the encryption path. Key material comes from the platform's cryptographic random source.
| Feature | Construction |
|---|---|
| Encrypted paste | AES-256-GCM, 96-bit random nonce per field |
| Encrypted drop box | ECIES: ephemeral ECDH P-256, HKDF-SHA256, AES-256-GCM |
| Threshold paste | Shamir secret sharing over GF(256), splitting the AES key |
| Time capsule | drand timelock (tlock), BLS on G1, quicknet beacon |
| Dead-man's switch | AES-256-GCM over the payload |
| Paste password | bcrypt, per-paste salt, server-side |
| Edit keys and API keys | 192-bit random tokens, stored as SHA-256 |
Where the keys live
The rule is that a key for end-to-end encrypted content never reaches a server.
- Keys travel in the URL fragment, the part of a link after
#. Browsers do not send the fragment to the server, so we never observe it. It is in your link and in your recipient's link, and nowhere else. - Every response sets
Referrer-Policy: no-referrer, so following a link out of a paste cannot leak the address you were on. - Crash reports carry the path you were on, never the full address, so a key cannot ride along inside one.
- Our service worker deliberately does nothing: it caches nothing and deletes any cache it finds, so a key can never be left behind in browser storage.
What we can and cannot see
For a paste created with end-to-end encryption:
- We cannot see the contents, the filenames, or the title. All three are encrypted before any network request happens.
- We can see that the paste exists, its short link, its size, when it was created and when it expires, how many times it has been viewed, its syntax-highlighting language, and the IP address that created it.
Content processing is skipped entirely for encrypted pastes. The spam heuristic, the abuse filter, and content analysis all require readable text, so none of them run. Encrypted pastes are also forced to unlisted, so they are never listed, indexed, or served in the public archive.
What is not end-to-end encrypted
Being specific about these is the point of this page. Encryption on Pastepile is opt-in, and several features protect something narrower than the phrase suggests.
- Password-protected pastes. The password is a server-side gate, not encryption. We hold readable content. This is why a paste can be password-protected or end-to-end encrypted, never both: combining them would imply a guarantee neither provides.
- Time capsules seal the body, not the labels. The content is genuinely locked until its unlock time and nobody, including us, can open it early. The title, filenames, and language are stored in the clear and are readable before then.
- Dead-man's switches that use escrow. If you enable escrow so we can email your recipient a working link, the key is stored on our side next to the ciphertext. Created without escrow, the key stays in your link only.
- Drop box labels. Submissions and sender names are sealed. The box's existence, its label, its prompt, and when submissions arrived are not.
A standard paste, with no encryption chosen, is stored as plain text and we can read it.
What this prevents
| Threat | Why |
|---|---|
| Someone intercepting the network | The payload is already ciphertext before it is sent. |
| Us reading your encrypted pastes | The key is never transmitted. We hold ciphertext and nothing that decrypts it. |
| A stolen database or backup, for encrypted content | Same reason. No key for encrypted content is stored anywhere on our side. |
| Offline guessing of paste passwords | bcrypt with a per-paste salt, which is deliberately slow, not a fast hash. |
| Guessing a share link | 192-bit random edit keys and unguessable slugs. Encrypted pastes are always unlisted. |
| Tampering with stored ciphertext | AES-GCM authenticates what it decrypts, so altered ciphertext fails rather than decrypting to something else. |
| Swapping a drop box's public key in our database | The recipient key is pinned in the submit link, and compared before anything is sealed to it. |
What this does not prevent
- A malicious or compromised server. This is the ceiling on all encryption delivered through a browser, ours included. We serve the JavaScript that does the encrypting. A server that wanted your plaintext could serve modified code. Everything above assumes the application you receive is the one we intend to serve. If your threat model includes us actively attacking you, encrypt before pasting, with a tool you control.
- Cross-site scripting elsewhere in the application. Rendered markdown is sanitized against an allowlist and the known mutation attacks are regression-tested. An injection flaw elsewhere would still be able to run in your browser.
- Malicious browser extensions. An extension with permission to read the pages you visit can read the key in the address bar and the decrypted content on screen. No web page can prevent this.
- Metadata. Sizes, timing, view counts, and the syntax-highlighting language are visible to us. The language is left in the clear on purpose so a paste can be highlighted without being decrypted first, and that is a real metadata leak rather than one we would rather not mention.
- Anything after decryption. Once your recipient decrypts, the plaintext is theirs. Encryption controls who can read, not what they do next.
- Losing the key. There is no recovery and no reset. A lost link fragment is lost data. That is the direct cost of us not holding a copy.
Independent review
Pastepile has not been audited by an outside firm. The cryptographic behavior described here is covered by automated tests that run before every release, including the failure cases: wrong keys, corrupted and truncated ciphertext, altered authentication tags, malformed inputs, and key uniqueness across many encryptions. That is testing, not an audit, and we will not describe it as one. If an independent audit happens, this page will name the firm and the date.
Reporting a problem
Email security@pastepile.com. Scope and safe harbor are on the security page.