E2E Share

🔒 End-to-End Encryption

All file data is encrypted with AES-256-GCM entirely inside the browser using the Web Crypto API.
Files are split into 256 KB chunks. Each chunk receives its own cryptographically random 12-byte IV. The AES-GCM authentication tag (16 bytes) is appended; any single-bit tampering causes decryption to throw.
File names, MIME types, and sizes are themselves AES-256-GCM encrypted with the room key before leaving the browser. The server sees only opaque ciphertext — it cannot read what you are sharing.
Text snippets (up to 50 KB each, max 50 per peer) are encrypted with the same room key. The entire snippet list is serialised as JSON, encrypted as a single payload with a random IV, and broadcast to all verified peers. No snippet data is ever stored on the server — it exists only in peers’ browser memory for the duration of the session.
The room file key is a random 256-bit AES-GCM key generated by the host each session. It never reaches the server in the clear.

🔐 Key Derivation

SPAKE2+ password credentials are derived from the password before the WebSocket connection opens. The raw password, SPAKE2+ session keys, and file key never reach the server; only the blinded public shares and confirmation MACs are relayed.

PBKDF2 (SHA-256) with a high iteration count, targeting approximately 200 ms per guess on modern hardware, feeds the SPAKE2+ password parameters per RFC 9383 §3.2 using the P-256 curve. The verifier material is precomputed so neither side ever transmits the password.
The PBKDF2 salt is domain-separated and deterministic. The deterministic design eliminates a network round-trip that would otherwise be needed to exchange a random server-generated salt.
The room file key is never derived from the password. It is a random AES-256-GCM key wrapped with an ephemeral session key from the SPAKE2+ handshake (see Peer Authentication Protocol) and regenerated fresh every session. No copy of it is ever stored on the server.
After derivation the password field is cleared and the app no longer needs the raw password for ongoing room state. (See Limitations regarding JavaScript memory guarantees.)

👥 Peer Authentication Protocol (SPAKE2+, RFC 9383)

Joining a room requires proving knowledge of the password before receiving any file key or file list. Authentication uses SPAKE2+, an augmented password-authenticated key exchange (PAKE) standardised in RFC 9383, with the P256-SHA256-HKDF-SHA256-HMAC-SHA256 cipher suite:

Joiner sends a join request with the room ID and derives the SPAKE2+ password parameters via PBKDF2.
Server records the joiner as pending and notifies the host.
Joiner generates a fresh ephemeral key, computes a blinded public share T, and sends it to the host.
Host generates its own ephemeral key, computes its blinded public share S, derives the shared session key, and sends S together with a key-confirmation MAC to the joiner.
Joiner verifies the host’s MAC (proving the host knows the password), then sends its own confirmation MAC back to the host. This is mutual authentication — both sides prove password knowledge.
Host verifies the joiner’s MAC. On success: the host wraps the room file key with an AES-KW-256 key derived from the shared session key and sends it to the joiner. Both ephemeral secrets are discarded immediately.
Joiner derives the same wrap key, unwraps the file key, and joins as a verified peer. The wrap key is then cleared from memory.
On failure or timeout: the joiner is disconnected and never receives any room data.

The server never sees the password, SPAKE2+ ephemeral secrets, session keys, or file key — it only relays the blinded public shares and confirmation MACs as opaque bytes. Because SPAKE2+ is a PAKE, even an eavesdropper who captures the full handshake cannot mount an offline dictionary attack against the password.

Forward secrecy. The room file key is regenerated fresh every session and never stored. Even if the password is later compromised, a captured network trace cannot be decrypted — the ephemeral scalars that protected the key exchange no longer exist.

Server MITM resistance. Both public shares (T and S) are cryptographically bound into the SPAKE2+ transcript hash. A compromised server cannot substitute either party’s share without causing the key derivation to diverge — the confirmation MACs will fail and the peer will be rejected.

🔃 Transfer Integrity

Chunk sequencing. Each chunk’s 4-byte big-endian sequence number is bound into the AES-GCM authentication tag as additional authenticated data. A reordered, replayed, or missing chunk causes authentication to fail on decryption — the receiver rejects it immediately.
Sender verification. Each binary frame carries the sender’s peer ID in its header. The receiver checks it against the expected source; injected chunks from a rogue peer are dropped before decryption.
Size validation. Received bytes must not exceed the declared file size. A transfer that violates the limit is aborted. On completion, the total must match exactly — silently truncated files are rejected.
Idle watchdog. A per-transfer timer cancels any download that stalls for 30 seconds, preventing a malicious or disconnected peer from holding resources indefinitely.
Backpressure & stall protection. The server monitors send-buffer depth on each socket. When a slow receiver causes the buffer to grow beyond a threshold the sender is paused. If the buffer never drains, the stalled connection is terminated — preventing a malicious peer from stalling uploads forever.
Filename sanitisation. Downloaded filenames are stripped of control characters, path separators, leading dots, and OS-reserved names to prevent directory-traversal or file-overwrite attacks.

📎 Supply-Chain & Asset Integrity

At startup the server computes SHA-256 hashes of all client-side assets from disk.
These digests are injected as integrity="sha256-…" attributes into the HTML before it is served. The browser refuses to execute any asset whose hash does not match — a tampered CDN or compromised server cannot silently inject malicious code.
Assets are served at content-hashed URLs with one-year immutable cache headers, ensuring stale caches never serve old or modified code without detection.
SHA-pinned reverse proxy image. The reverse proxy container image used in production is referenced by its full sha256 digest, not just a mutable tag. A compromised registry cannot silently substitute a different image for the ingress layer.
Frozen lockfile. All dependencies are installed from an exact, reproducible lockfile. A man-in-the-middle cannot inject or upgrade a package at build time.
Vulnerability scanning. Every build is scanned with Trivy for known CRITICAL and HIGH CVEs. Any unfixed vulnerability fails the build and blocks deployment.
Minimal production image. Build tools, package managers, and development dependencies are stripped from the final image. This minimises the attack surface and eliminates transitive vulnerabilities that exist only in build-time tooling.
A catch-all 404 route blocks accidental exposure of any other files that might be added to the public directory.

🛡 Server-Side Hardening

Trusted Types — CSP enforces require-trusted-types-for 'script' with a single named policy. Every call to a browser injection sink must go through this policy, blocking DOM XSS at the API level regardless of what other code runs. All dynamically rendered HTML auto-escapes interpolated values.
Strict Content Security Policy — default-src 'self', same-origin scripts only, with SRI on served assets and no unsafe-inline or unsafe-eval. CSP violation reports are collected for monitoring.
Permissions-Policy — camera, microphone, geolocation, payment, USB, and other sensitive browser APIs are explicitly disabled. No page or embedded frame can activate them.
Cross-Origin Isolation — Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp prevent cross-origin data leaks and mitigate Spectre-style side-channel attacks.
HSTS — Strict-Transport-Security (2-year max-age, includeSubDomains, preload) ensures all traffic is encrypted in transit. HSTS headers are only sent over TLS to prevent downgrade attacks.
Rate limiting — per-IP limits on HTTP requests, WebSocket connections, room creation, and room joins. Per-socket message rates are also capped to prevent flooding. IPv6 addresses are bucketed by /64 prefix so clients cannot bypass limits by rotating through addresses in the same allocation.
Message validation — every inbound WebSocket message is schema-validated with a per-type field whitelist; unexpected fields or unknown message types are rejected before relay. Broadcast-only message types cannot be re-targeted to a single peer by injecting extra fields.
Size limits — JSON messages and WebSocket frames are capped at server-configured maximums.
Global capacity caps — limits on total rooms, concurrent connections, per-IP connections, and peers per room. Rooms with no peers are garbage-collected to prevent slot-squatting.
Orphan socket timeout — connections that never join a room are terminated after a short grace period, preventing idle sockets from consuming global connection slots.
Keepalives detect dead connections and reclaim server resources promptly.
Server fingerprint suppression — technology-identifying headers are removed and DNS prefetching is disabled to minimise information leakage.
Slow-HTTP defence — strict timeouts on request headers, request bodies, and idle keep-alive connections prevent slowloris-style attacks.

📦 Container & Deployment Hardening

Non-root execution. The application process runs as an unprivileged user inside the container. Even if an attacker achieves code execution, they have no elevated OS privileges.
Read-only filesystem. The container’s root filesystem is mounted read-only. Only an explicit temporary-file mount is writable, limiting what a compromised process can modify.
Dropped capabilities. All Linux capabilities are dropped and privilege escalation is blocked. The process cannot gain any kernel-level permissions it was not started with.
Resource limits. Memory and process-ID caps prevent denial-of-service via memory exhaustion or fork bombs.
Network isolation. The application container is not directly exposed to the internet. Only the reverse proxy has a public-facing port, and it communicates with the application over an isolated internal network. Client-supplied forwarding headers are stripped and re-set by the proxy from the true remote address, preventing IP-spoofing.

👁 What the Server Can and Cannot See

⚠️ Honest Limitations

JavaScript memory erasure is best-effort. Clearing password inputs and dropping references reduces exposure, but the runtime may retain string copies until garbage collected. True memory-zeroing is not possible in browser JavaScript.
The password is the root secret. A weak, guessed, or leaked password defeats all cryptographic protections. Share it out-of-band — never in the same channel as the room ID.
Browser trust boundary. End-to-end security assumes your browser, OS, and installed extensions are uncompromised. A keylogger or malicious extension can intercept the password before it reaches the crypto layer.
Transfer timing is visible. The server can observe when transfers occur, approximate sizes, and which peers are active — even though it cannot read the content.
Room ID is not secret. The room ID is sent to the server and may appear in URL history. Only the password is secret; the room ID is just an address.

Create a Room

Join a Room

Enter Room

⬆ Uploads

⬇ Downloads

Activity