My friend and former colleague has built a bunch of stuff over magic-wormhole like fowl[0], shwim[1] and so on. There is a lot of nice work on "dilated" wormhole.
And its lesser known component, the mailbox server used for signaling to connect the two computers. If you’ve ever installed and used magic wormhole, you’ve likely used the default public mailbox server unless you configured and set up your own.
Debian was kind enough to configure their distribution's copy with a distinct hostname for the transit relay helper (the bit that forwards bulk encrypted traffic when both parties are behind NAT). "magic-wormhole-transit.debian.net" is currently a CNAME for "transit.magic-wormhole.io" (which is what the upstream source uses), so all this currently costs them is some DNS maintenance. Both sides exchange transit server hostnames, so they don't need to use the same one, but Debian does this so we could switch Debian-based clients off to a different server if/when my costs of running transit.magic-wormhole.io grow too large.
The "mailbox relay server" for all mutually-communicating clients must be the same. Both upstream and Debian (and most of the other distributions I've seen) use "relay.magic-wormhole.io". The mailbox server helps the clients exchange tiny key-exchange and setup messages, so its costs are trivial.
Note that it's less clear how secure croc is. Magic Wormhole would be the reference there, I think. I have seen issues on the croc repository regarding security, not sure what the state is today.
Granted croc supports resuming transfers, which magic wormhole doesn't.
coc is also available on android which maked it really useful. Although kde connect works very well at least for smallish files, it requires pairing devices you might not want to pair permanently.
This project made me learn about and attempt to implement the SPAKE2 protocol and HKDF as an exercise.
It's quite fascinating. It lets you upgrade a short password to a long key, but requires trusting a server to rate limit attempts on brute-forcing that short password. It seems difficult to find a practical use case for it tho. Because it's only relevant when it is impractical to send a long key. But if you think for a second, lets say you are transferring from a desktop to a phone, you can show a QR code and scan in with your phones camera, thus achieving a secure handshake bypassing the need for SPAKE2 all together. Maybe it would defeat the simplicity of the tool, but if it also provided a long string of words for the key, a user could optionally send all the words instead of just the first few and get themselves a secure key without needing to trust the server.
> requires trusting a server to rate limit attempts on brute-forcing that short password
This isn't true. Particularly, if an attacker attempts to connect with the wrong password, this will be seen by the client, which then aborts the connection. So an attacker can only try one password. You can test this yourself:
A: $ wormhole send foobar
A: Wormhole code is 1-whimsical-klaxon
B: $ wormhole receive 1-klaxon-whimsical # wrong password
B: ERROR: Key confirmation failed. Either you or your correspondent
B: typed the code wrong, or a would-be man-in-the-middle attacker guessed
B: incorrectly. Try sending the file again.
B: <exit>
A: ERROR: Key confirmation failed. Either you or your correspondent
A: typed the code wrong, or a would-be man-in-the-middle attacker guessed
A: incorrectly. Try sending the file again.
A: <exit>
So if you receive this error (potentially repeatedly), you learn that there is an attacker trying to guess passwords. You can then choose to increase code length or simply stop using that channel.
The CLI also has an option to further mitigate MITM attacks with the `--verify` flag -- this shows to both clients a hash of the transcript, which can be verbally verified before proceeding with the transfer. This allows detecting an attack even if the attacker gets the password right on the first try (which has probability 1/65536).
Does that mean if 100 people send files over a server, and out of the 100 recipients a single one spells the code wrong, all 100 transfers get cancelled?
No, the key negotiation occurs between two clients.
In the Magic Wormhole protocol, the number at the beginning of the Magic Wormhole phrase specifies a "nameplate" used to negotiate the "mailbox" which both clients (sender and receiver) use. If a recipient specifies a _matching_ nameplate but a _non-matching_ key phrase, the file transfer transaction between the sender and receiver with a matching nameplate will fail (since they cannot correctly produce a shared key), but nobody else is affected in any way.
An evil attacker could DoS the magic-wormhole mailbox server by spamming mailbox nameplates with bad keys, since there isn't much entropy at all there, but they would affect only single transactions at a time.
That's all nice and dandy, but what about sending data the other way, from a phone to a desktop? Meticulously typing in long strings of text with no mistakes is not really a practical solution for the vast majority of users.
Localsend, if you're on the same wifi network. Works decently for sending files between Android/iOS/Desktop (sometimes on iOS the app must be closed and reopened a couple of times before non iOS devices can detect it, for some reason).
I use magic wormhole everywhere else, servers, vms, etc.
You can still generate the QR code in the desktop and scan it with your phone camera. The device receiving the file does not have to be the device that scans the code.
Maybe if your camera is broken? Or you are using one of those phones built without a camera (like the ones issued to people who work at secure government sites)?
I use this all the time when trying to get files between devices that need multiple hops to get to. Way easier then remembering what scp or rsync combo I need to jump through a host
> Because of firewall network address translation (NAT) issues, rendezvous protocols generally require that there be at least one unblocked and un-NATed server that lets the peers locate each other and initiate concurrent packets at each other.
So probably cant help with a VPC unless you pierce a hole for it.
I guess this makes sense, since by design this shouldn't be possible.
The point of the intermediate server is so that you can NAT hole punch, otherwise it has little point (except maybe as a relay, which is a bad solution).
We're making good progress on hole-punching, but it isn't available yet. Once complete, that should take some pressure/cost off the transit relay machine.
Note that the transit relay only sees ciphertext (for bulk data transfers). Even the mailbox server only sees ciphertext or SPAKE key-exchange messages. No server sees plaintext ever.
Thanks for the clarification. I didn't say the relay server is a bad solution because of transfer security (although it could be an issue), but rather because it is expensive in terms of bandwidth and so is unlikely to exist long-term.
There exists winden.app which is a magic wormhole webapp. They use their own mailbox and relay so you need to use the right options in the wormhole CLI.
I prefer https://localsend.org/ nowadays. Nice cross-platform GUI, "just works". Requires being on the same lan, but discovery of other devices is automatic and there are no alphanumeric codes that have to be shared. It's a good QoL improvement to have "airdrop" between Android and Linux
I've had better luck with https://drop.lol/ - it allows local discovery but can also share a link (drop.lol/XXXXX) to invite a device to the "network". There have been a number of times/networks local peer discovery doesn't work for me, but maybe that's because I haven't installed the localsend app.
You need to be sure to use a sufficiently strong password/passphrase for PGP symmetric encryption. For GPG I would use at least 4 diceware words. The thing being discussed here only requires a digit and 2 words due to the use of a PAKE.
It would be nice if things like GPG would generate an appropriate passphrase for you by default.
I guess if you are only going to send one file the difference is not really all that significant. Otherwise the experience after exchanging email addresses and fingerprints would probably be better with encrypted email.
I’ve used this and localsend, both are great, but has anyone finally solved the problem of making one of these things that can use a GUI (for phones and tablets) and also a CLI (for when I’m SSHed into my home computer and need to send a video to get processed by something)?
I need iOS and iPadOS. Although ideally there’d be a GUI that could work on all of the “mainstream” OSes, since most of my problem here is that I frequently need to move files between devices in different walled or unwalled gardens.
For desktop PCs, Rymdport (formerly wormhole-gui) may be suitable. It's cross-platform with pre-built binaries for FreeBSD, Linux, macOS and Windows on x86-64 and arm64:
If you don't mind unencryption or are okay with encrypting/decrypting things yourself via standard tools (don't worry you could probably create a shell alias to do that for you in ssh)
Personally I don't really mind the unencryption as I mean I just use it to pass videos or any software and I don't really think that there are any security concerns but its also really easy to encrypt / decrypt as well so I genuinely recommend it
It can actually work out of the browser and in the ssh server by using curl / maybe even wget but no guarantees. Both standard tools.
No CLI yet but mobile & desktop support (yes, including Linux), LAN & online: https://payload.app/
Focused on speed, so good for video. (If your transfers don’t saturate the network I treat that as a failure and a bug to be fixed - please report if speed is ever lacking)
Folks at Coder authored a p2p file transfer tool using Tailscale (no account needed, the setup is entirely ephemeral, and the code apparently runs a Headscale control server in-memory): https://github.com/coder/wush
Unsure how Tailscale rate limits, if at all, such traffic flowing through its public relays ("DERP"), as a tool like this is just ripe for abuse?
A simple encrypted channel for file transfer. A great way to send a file to a stranger who is near you but shares nothing with you, e.g. at a conference.
/* A modern version should, of course, work in a browser, so that there'd be no Python packages to install. But the browser security model does not allow listening, so a signaling server would be needed to create a WebRTC connection. It could run on one of the devices involved, but still can't be a pure web app. */
> A modern version should, of course, work in a browser, so that there'd be no Python packages to install
Now, only uv needs to be installed (two self-contained binaries). Then you can do `uvx magic-wormhole --help` and it will quickly create a transient environment with the required packages. You don't even need to install Python (uv will do a transient install of Python as well).
There are Rust and Haskell implementations too (not quite as feature-full as the Python code yet, though) as well.
In principal WebRTC communication could be added to magic-wormhole, but that work has not been done yet. There is WebSocket support in the relay (including "cross-protocol" so one client can be WebSocket and the other TCP). This is only deployed on the Winden.app servers (tcp://relay.mw.leastauthority.com:4001 and wss://relay.mw.leastauthority.com for the relay).
You'd need to use the Winden.app relay server if you want https://winden.app users to reach your Python CLI (e.g. via "wormhole --relay-url wss://mailbox.mw.leastauthority.com/v1 send" for example)
They don't have to be near you, they can be over the internet. Relatedly, the Magic Wormhole CLI also depends on a signaling server (referred to in the documentation as the "mailbox"), so I don't think it's doing anything you couldn't do with WebRTC.
"Near you" physically only matters in coordination, not the network. I can beside someone and it will still go towers and space before we establish a connection.
Been using it from time to time to transfer secrets; out of curiosity, when I'm sending something to some via this tool, do you known what machines is it relayed through? I am sure it's not peer-to-peer; would not be as reliable!
Both sides connect to the "mailbox relay server" to perform key exchange and setup. That's a host named "relay.magic-wormhole.io".
If either side has a public IP address, the encrypted data is transferred directly (they exchange IP addresses through the encrypted pipe, and attempt to connect to all of them, so this also covers two peers on the same LAN). If neither do, they both connect to a public "transit helper" relay named "transit.magic-wormhole.io" which acts like a TURN server to get the encrypted bytes from one connection to the other. I run both services.
I did use it some time ago, but I remember the user experience being somewhat confusing, since there are multiple similarly named tools around, which don't seem to be interoperable. Still, a cool concept.
I’m glad to see that there are mobile apps and web applications that work on/use Magic Wormhole for peer to peer file transfers. The mobile app and web applications seem to be limited (number of files is one at a time, size of file allowed, etc.) due to limitations on mobile platforms and due to choices by the developer/server host.
Strong recommend. When I’m bouncing around getting onboarded on new client/customer machines that disallow syncing (justifiably), magic wormhole is a fabulous way to get my dot files and local env set up in a jiffy. Works well for secure transfer of _large_ files ad hoc, too, so a great fit for db dumps.
I use magic wormhole when I first install a computer to send an SSH key. At that point, I have ssh. Also if you use a mesh VPN, your devices are already connected and there are several ways to transfer files.
I like to use it more. What is your use case for this?
FYI, there's a subcommand just for this use case: `wormhole ssh invite` / `accept`, which will read the SSH pubkey on one end and append it to authorized_keys on the other.
If you’re launching machines from a prebaked image or template, it may not be possible to inject/generate something unique for each one, or doing so is finicky to the point that using something like wormhole may be simpler than fighting with your provisioning tool.
1. i wish syncthing also would implement this
2. is it already postquantum secure?
(to all the quantum-computer-will-never-come-people: i like to be prepared in CASE it comes, otherwise no one will prepare and users are in the dust, once it is there)
I am not a cryptographer, but can explain that Magic Wormhole uses SPAKE2 to negotiate a shared secret (RFC9382 claims equivalent to gap Diffie-Hellman), and then uses NaCl SecretBox to symmetrically encrypt all data between the peers.
(If using the newer Dilation protocol -- which is true for many of the non-file-transfer tools like ShWiM, Git-WithMe or Fowl -- peer traffic uses this shared secret with Noise, specifically "Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s")
- NAT Traversal: WireGuard typically requires at least one publicly-reachable endpoint. Magic Wormhole's relay server handles NAT traversal for initial rendezvous, then attempts direct connection.
- Configuration: WireGuard needs config files with public keys and endpoints. Magic Wormhole just needs a temporary code.
- Layer: WireGuard operates at network layer (creates virtual interface, routes IP traffic). Magic Wormhole is application-level.
[1] Based on a conversation with Claude 4.5, distilled and lightly edited. This information matches my experience with them.
I use this very specifically for setting up new machines. It's one of those where I don't use it much, but when I do it has saved me a whole lot of time, and it's worked well every time.
[0] <https://github.com/meejah/fowl>
[1] <https://github.com/meejah/shwim>