Magic Wormhole: get things from one computer to another, safely

Original Article ↗ Hacker News Discussion ↗

Use cases and advantages

  • Widely used for ad‑hoc, one‑off file transfers, especially:
    • When SSH/scp accounts or keys are not preconfigured.
    • Across NATs/firewalls where inbound connections are blocked.
    • Onto locked‑down or GUI‑less machines and into corporate environments.
  • Favored for simplicity: wormhole send FILENAME / wormhole receive CODE, no account setup, no user management.
  • Seen as complementary to tools like rsync and Syncthing:
    • Analogy: wormhole : Syncthing :: scp : rsync.
    • Good for “introduction”/bootstrap; Syncthing better for ongoing sync.

How it works: servers, NAT, and performance

  • Uses two servers:
    • “Mailbox” server for small control messages and PAKE exchange.
    • “Transit relay helper” only if direct connectivity fails (both sides behind restrictive NAT).
  • Tries all known IPs on both sides first; relay is fallback.
  • Relay bandwidth reported around 10–15 TB/month; some worry about scalability, others note it’s manageable and tunable.
  • Hole-punching/WebRTC/STUN‑style techniques are partially implemented in the Rust ecosystem and planned for Python; current Python version lacks full NAT punching.
  • Some users report large transfers (tens of GB) working well; one critic notes throughput ~20 MB/s over high‑latency links and calls for multi‑stream/UDP‑based protocols.

Security model and concerns

  • Uses a short, human‑readable code (channel + ~16 bits entropy) fed into a PAKE.
  • PAKE limits attackers to one guess per protocol run; wrong guesses abort the session, making brute force self‑limiting.
  • Tab‑completion on words is argued to not leak entropy, since the wordlist is fixed.
  • A commenter highlights a theoretical 1/65,536 hijack chance and argues it’s weaker than SSH; others accept this tradeoff for usability.
  • Not post‑quantum‑secure; some discuss layering GPG or using PQ‑secure key exchange separately.

Ecosystem and alternatives

  • Multiple interoperable implementations: Python (feature‑rich), Go (“wormhole‑william”), Rust (used by GNOME Warp and Android apps), Haskell.
  • Various GUIs and wrappers: Warp, Android clients, RiftShare, mobile APKs, npx wrapper.
  • Many alternative tools discussed (croc, Syncthing, Tailscale Taildrop, LocalSend, sharedrop/snapdrop/pairdrop, Send Anywhere, Zynk, etc.), each with different tradeoffs (P2P vs relay, repeated sync vs one‑shot, FOSS vs proprietary).

Limitations and UX issues

  • Requires Internet access; no fully offline/local‑only mode yet (mDNS/Bonjour design ideas remain unimplemented).
  • Multi‑file/incremental transfer is weak (zips everything, no resume).
  • Installation can be dependency‑heavy on some platforms; users suggest more one‑click binaries and clear platform‑specific downloads.
  • Some admins view it as a policy risk because it enables encrypted outbound file exfiltration that bypasses traditional controls.