Paste & Purge Security Architecture
An in-depth technical analysis of our zero-knowledge cryptographic implementation, client-side key isolation, atomic server-side purging, and operational threat model.
1. Cryptographic Threat Model & Core Invariant
Traditional secret-sharing platforms receive sensitive credentials over TLS and encrypt them on their own servers. Under that model, anyone with database access, server access, or memory snapshot privileges can read user secrets.
"The Paste & Purge server infrastructure never receives, processes, or possesses the decryption key or unencrypted plaintext for any user secret."
Even if our database is fully breached, our server memory inspected, or our network traffic captured, the stored payloads remain uncrackable ciphertext without the client-held keys.
2. Cryptographic Algorithms & Specifications
- API: Native browser W3C Web Crypto API (
window.crypto.subtle). - Cipher: AES in Galois/Counter Mode (AES-GCM) with 256-bit keys.
- Initialization Vector (IV): 96 bits (12 bytes) of cryptographically secure random entropy generated via
crypto.getRandomValues()per encryption operation. - Integrity Tag: 128-bit authentication tag appended to ciphertext to detect tampering.
- Payload Limit: Enforced client-side and server-side limit of 10,000 UTF-8 characters.
- Algorithm: PBKDF2 (Password-Based Key Derivation Function 2) per RFC 8018.
- Pseudo-Random Function (PRF): HMAC-SHA-256.
- Iteration Count: 600,000 iterations (exceeding OWASP password hashing recommendations).
- Salt: 128 bits (16 bytes) generated via
crypto.getRandomValues()for each secret. - Derived Key: Non-extractable CryptoKey imported directly into SubtleCrypto.
3. Client-Side Key Isolation via URL Hash Fragments
The foundation of web-based zero-knowledge systems relies on internet standards for Uniform Resource Identifiers. According to IETF RFC 3986, Section 3.5:
"The fragment identifier component of a URI allows for indirect identification of a secondary resource... Fragment identifiers are not transmitted to the server when resolving a URI."
When Paste & Purge generates a secret link:
4. Data Access Matrix: What the Server Can vs. Cannot See
| Data Element | Server Access Status | Technical Reason / Protection |
|---|---|---|
| Plaintext Message Content | Cannot Access | Encrypted in browser with AES-256-GCM before transmission. |
| 256-bit Decryption Key | Cannot Access | Stored in URL hash fragment; stripped by browser per RFC 3986. |
| User Passphrase (Optional) | Cannot Access | Derived locally via 600,000 PBKDF2 rounds; never transmitted. |
| Encrypted Ciphertext Bytes | Can Access | Stored ephemerally until burned or expired. Indistinguishable from random noise. |
| 12-Byte IV & Salt | Can Access | Public cryptographic parameters required for recipient decryption. |
| TTL Expiration & View Counter | Can Access | Required by server to enforce access limits and trigger automatic deletion. |
5. Atomic Purging & Database Deletion
When a recipient requests a secret payload:
- Single-View Secrets: The database read and delete are executed atomically in a single database transaction. The ciphertext is returned to the client and immediately expunged from persistent storage.
- Subsequent Requests Return HTTP 410: Once a secret is purged, any future GET requests return an immutable
410 Gonestatus code. - Multi-View Limits: For secrets configured with 2, 5, or 10 views, each retrieval decrements the counter atomically until zero is reached, triggering immediate deletion.
- Automated Background Sweeps: Unopened secrets that pass their expiration threshold (5m, 15m, 1h, 24h) are purged continuously by background cleanup tasks.
Realistic Security Boundaries & Limitations
In the interest of complete transparency, no security tool provides absolute protection. Users must evaluate their specific threat models against the following operational realities:
If the sender's or recipient's machine has malware, a hardware keylogger, or malicious browser extensions, the plaintext can be stolen directly from device memory or screen buffers.
Once a secret is decrypted in the recipient's browser, Paste & Purge cannot prevent them from copying, saving, photographing, or re-transmitting the text.
If the secret link is transmitted over an unencrypted or compromised chat channel, an eavesdropper could intercept the link and burn it before the recipient. (Use password protection to mitigate this).
Because we cannot decrypt your secrets, lost links or forgotten passphrases are permanently unrecoverable. Do not use Paste & Purge as your only copy of critical information.