Wormhole Transfer

This page describes what protections are in place, what the server can and cannot see, and what assumptions the security model rests on.

All file transfers use the magic-wormhole protocol:

• SPAKE2 — Password-Authenticated Key Exchange. Both parties prove knowledge of the wormhole code without transmitting it. The result is an ephemeral session key that is unknown to the relay.
• AES-256-GCM — All file bytes are encrypted and authenticated before leaving the sender. Tampering with ciphertext in transit is detected and rejected.
• TLS 1.2+ — All browser connections use HTTPS and WSS. The Let's Encrypt certificate is auto-renewed.

• IP addresses of both sender and receiver (standard server access logs)
• File size and transfer timing
• File name (sent in plaintext as part of the wormhole handshake metadata)
• Encrypted file bytes while they pass through the transit relay — ciphertext only, not plaintext content

The upload path (browser → server) sends the file in plaintext over TLS to the server before it is handed to the wormhole subprocess. The server therefore briefly holds the decrypted file on disk in a temporary directory. This is deleted immediately after the recipient downloads it.

• File content after it has been AES-GCM encrypted for wormhole transit
• The wormhole session key (derived client-side via SPAKE2 — never transmitted)
• Anything about transfers it did not relay

• Uploaded files are stored in a temporary directory (/tmp/whs-*) and deleted as soon as the recipient downloads them, or when the transfer session ends (success or failure).
• No files are logged, archived, or backed up.
• Server access logs (IP, timestamp, HTTP method, path) are kept for up to 30 days for operational purposes.
• No analytics, no cookies, no tracking scripts of any kind are used.

This deployment runs its own private mailbox and transit relay (Magic Wormhole server software, Docker containers on the same host). No traffic touches the public magic-wormhole.io relay servers operated by third parties.

This means all relay metadata stays on this server. It also means availability depends on this server rather than a third-party service.

• Code interception: If an attacker intercepts the wormhole code before the recipient enters it, they can receive the file instead. Protect the code in transit the same way you would protect the file itself.
• Server compromise: If this server is compromised, an attacker could intercept files during the upload phase (before wormhole encryption). End-to-end security in the strictest sense requires a client-side implementation. This server-assisted model prioritises accessibility (no install) over that guarantee.
• TLS is required: Do not use this service over HTTP. All links enforce HTTPS.
• Single-use codes: Each code works exactly once. A failed or intercepted transfer consumes the code; the sender must start a new transfer.

The underlying protocol is implemented by the magic-wormhole open-source project (MIT licence). The cryptographic primitives (SPAKE2, AES-GCM) are standard, peer-reviewed algorithms. No proprietary or novel cryptography is used.