How Twinpad's end-to-end encryption works
How Twinpad keeps your text, passwords and files private: keys derived in your browser, AES-256-GCM, and a server that only ever sees ciphertext.
"End-to-end encrypted" is easy to claim and hard to check. This page explains exactly what happens to your data in Twinpad, what the server can and can't see, and where the limits are. No marketing, just the mechanism.
The short version
- Your browser generates a random session password and derives the encryption key from it. The key never leaves your browser.
- Everything you add (text, secrets, file contents, file names, device names) is encrypted with AES-256-GCM before it's sent.
- The server stores and relays only ciphertext. It can't read your content, and neither can anyone who gets access to the server's storage.
- All session data lives in memory and a temporary folder, and is deleted when the session expires or is destroyed.
From password to keys
When you create a session, your browser generates an 8-character password from a 31-character alphabet that leaves out look-alikes like 0/O and 1/I/L, plus a random 16-byte salt. From these it derives keys:
password + salt
└─ PBKDF2-SHA256, 310,000 iterations → master key
├─ HKDF "twinpad/enc/v1" → AES-256-GCM key (stays in the browser)
└─ HKDF "twinpad/auth/v1" → auth token (server stores only its SHA-256)
The two keys are independent: knowing the auth token doesn't help anyone decrypt. The server keeps only a hash of the auth token, so it can check that a device joining knows the password without ever learning the password or the encryption key.
What gets encrypted
Every piece of content is encrypted separately with a fresh random 12-byte IV. Each blob also carries additional authenticated data that binds it to its room and its purpose, and for file chunks, to the chunk's position. A server that tried to swap, reorder or replay blobs between rooms or files would make decryption fail instead of showing wrong data.
| Data | Server sees |
|---|---|
| Shared text (every edit) | Encrypted blobs |
| Secrets, labels and values | Encrypted blobs |
| File contents | Encrypted 1 MB chunks |
| File names and types | Encrypted |
| Device names | Encrypted |
| File sizes, number of devices, timing | Visible (needed for quotas and sync) |
The link and the QR code
A session link looks like twinpad.me/r/123456#k=ABCD2345. The part after # is the URL fragment, which browsers never send to a server. Twinpad reads the password from it and immediately removes it from the address bar, so it doesn't stay in your history or show up in a screenshot. Anyone who has the full link can join, so share it only with your own devices or people you trust, and lock the room once everyone's in.
Protection against guessing
- Per-IP limit: after 10 wrong passwords within 15 minutes, further attempts from that IP are refused.
- Per-room limit: after 25 wrong passwords a room locks itself, and every failed attempt is shown live to the devices in the room.
- No room enumeration: for codes that don't exist, the server returns a deterministic fake salt, so you can't tell real rooms from empty codes.
- Manual lock: once your devices are connected, lock the room and no one new can join, even with the right password.
Hardening in the browser
- A strict Content Security Policy: only Twinpad's own scripts run, with no inline scripts, third-party scripts, CDNs, analytics or ads.
- No cookies. Session tickets are kept in the tab's session storage and disappear when you close it.
Referrer-Policy: no-referrerand framing disabled, so other sites can't embed or observe Twinpad.
Limits you should know about
Honest security means stating the trade-offs:
- The session password is short (about 40 bits) so it's easy to type on a phone. Online guessing is blocked by the limits above, but whoever operates the server could try to brute-force it offline from the stored hash, which PBKDF2 makes slow but not impossible. Don't keep highly sensitive data in a session longer than you need to.
- You trust the code the server sends. As with any web app, a compromised server could serve modified JavaScript. That's the fundamental limit of browser-based encryption.
- Your devices must be trustworthy. Encryption doesn't help against malware on the device you're typing on.
- Metadata is visible to the server: when a session exists, how many devices joined, and how big the files are.
Twinpad is designed for moving things between your devices quickly and privately, not for long-term storage of secrets. See also the privacy policy.
Last updated