lotharrr

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.

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.

(author here)

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.

(magic-wormhole author here)

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.

I've been pretty happy with Unifi's "In-Wall" AP (e.g. https://store.ui.com/us/en/category/wifi-wall/products/u6-iw): PoE powered, has four downstream RJ45 ports (one with PoE itself), and is a side-firing WiFi AP as well. Like the sibling comment said, they're made for hotel rooms, but I've never been in a hotel fancy enough to use them (possibly because the RJ45 sockets aren't particularly discoverable, being on the bottom). It doesn't live in a power outlet, but it's meant to be mounted at the same height. Worked great for my home office. (I'm not associated with Unifi, just happy with their gear)

One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.

I think it's a 2-out-of-3 trilemma: end-to-end encryption, short codes/URLs, offline/non-interactive workflow: choose two. Or framed differently, if you require proper encryption, then either the code/URL must be long enough to hold the full key, or you must use an interactive (PAKE) protocol which means both agents must be running at the same time (babysitting).

Your last point is an interesting one: we could build a form of magic-wormhole where the sender's CLI waits, the recipient gets a URL, the URL points to a web page which performs the client side of the protocol. The server wouldn't host the file, just the decryption agent. Basically wormhole receive in a browser. That would match many of your goals.

However I'd be hesitant to do this with magic-wormhole because it opens up a vulnerability we don't currently have: the web server hosting that page could silently swap out the JS with a version that retained a copy of the plaintext, perhaps only when the browser is coming from a specific IP. You can't audit a webserver for consistent+correct behavior the way you could with e.g. the contents of a Debian distribution.

That said, the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.

(I'm the author of magic-wormhole)

WebRTC (and the various hole-punching techniques listed elsewhere here) have mechanisms to help with most cases of both participants living behind NAT boxes. The remaining cases require some sort of relay that is willing to proxy the connection through the extra-strict NAT layers.

Tor is basically a distributed set of proxy servers, so using onion servers (aka Hidden Services) is a viable, albeit somewhat slow, way to manage even the strict NAT boxes.

If you have Tor installed, then `wormhole send --tor` will automatically use an onion service to do exactly that.

Nope. It needs to contact the "mailbox server" to coordinate the rest of the protocol. Two machines with local connectivity (e.g. on the same LAN, but your WAN connection is broken) could still implement the second half of the protocol, where they use each other's IP addresses to make a direct connection, but without the first half they couldn't learn those addresses or exchange the key-negotiation messages.

We've sketched out some approaches to working in a disconnected environment like that, using local multicast and mDNS/ZeroConf/Bonjour to act as an alternate mailbox server (https://github.com/magic-wormhole/magic-wormhole/issues/48). There's still design work needed, though, and I fear it would degrade the experience for fully-connected nodes (extra timeouts), so it might want to be opt-in with a `--offline` flag on both sides.

Correct. The wormhole code is a channel number (called a "nameplate") and a short secret, which defaults to 16 bits of entropy. The secret is used as the input to a PAKE, which only gives the other party (hopefully your intended recipient, but maybe an attacker) a single guess. The security of the protocol stems from the PAKE algorithm: yes, someone might jump into your conversation and attempt to guess the secret, but they're going to guess it incorrectly most of the time, and each time they fail, the connection is interrupted, and you (the sender) get an error. You'll probably give up well before they get a reasonable chance of success.

The secret can be any string you like, the protocol doesn't care, instead of "4-purple-sausages" it could be "4-65535" or "4-qtx", and have the same resistance to attack. The CLI encodes the secret as two words from the PGP word list, which was designed to be spoken and transcribed accurately even over a noisy voice channel (sort of like the Alpha/Bravo/Charlie/.. "military phonetic alphabet", except it's two alternating lists of 256 words each). In practice that pair of words is much easier to speak and listen and hold in your head for a minute or two than a random number, or the first two letters of each word divorced from the words themselves.

There are some provisions in the protocol (not yet implemented) to allow alternate word lists, so if the sender uses e.g. a French wordlist instead of the default English one, the receiving CLI learns about it early enough so that "wormhole rx" can auto-complete against the correct list. The server/attacker could learn which wordlist is in use, but still faces the same level of entropy about the PAKE secret itself.

The PAKE algorithm lets you spend an interactive roundtrip to buy a full-strength key out of a weak shared secret. An attacker can attempt to guess the passphrase, and their chances are non-zero (one out of 65536 with the default configuration), but when they guess wrong, the whole protocol shuts down, and the real participants have to start over again, with a new code. So the only way for the attacker to win is for you to restart over and over again until they get lucky. Kinda self-limiting that way :).

https://github.com/magic-wormhole/magic-wormhole/blob/master... has a larger writeup.

I don't know of one yet, but I tried to choose protocols (websockets) that were friendly to being hosted in a browser, or a browser plugin. The exception is the bulk-transfer protocol, that's pure TCP, which can't be used by plan web content, although I think browser plugins might be allowed to. The upcoming Dilation protocol should be more flexible on this dimension.

Magic-wormhole is really intended to help with the first-step "introduction" phase of a tool like that: start with two humans that can yell a codephase at each other, and finish with two computers that have a secure encrypted connection. Once you've got that connection, you can send whatever you want through it.

The `wormhole send` tool is a good demonstration of what you can do with that API, and a convenient tool in its own right, but wasn't designed to be the end-all-be-all of the file transfer universe, nor to be a building block for other tools layered on top.

The application you describe would be pretty cool (the UI might look more like dropping a file into a Slack DM chat window). But I'd recommend against using automated calls to `wormhole send` to accomplish it: you'd be cutting against the grain, and adding load to the mailbox server that everyone else uses. Instead, build a separate app or daemon, which can use the magic-wormhole API to perform just the introduction step. You'd push the "invite a peer" button on your app, it would display a wormhole code, you speak that to your pal, they push the "accept invitation" button on their app, type in the code, and then the two apps exchange keys/addresses. All subsequent transfers use those established keys, and don't need to use the wormhole code again. You should never need to perform a wormhole dance more than once per peer.

It can't hurt, but it shouldn't be necessary. The client-side software establishes an encrypted connection with its peer, using an encryption scheme that should be just as secure [but see below] as what GPG or SSH will give you.

For GPG to add security, you also have to make sure the GPG key is transferred safely, which adds work to the transfer process. Either you're GPG-encrypting to a public key (which you must have copied from the receiving side to the sending side at some point), or you're using a symmetric-key passphrase (which you must generate randomly, to be secure, and then copy it from one side to the other).

I should note that magic-wormhole's encryption scheme is not post-quantum -secure. So if you've managed to get a GPG symmetric key transferred to both sides via PQ-secure pathways (I see that current SSH 9.8 includes "kex: algorithm: sntrup761x25519-sha512@openssh.com", where NTRU is PQ-secure), then your extra GPG encryption will indeed provide you with security against a sufficiently-large quantum computer, whereas just magic-wormhole would be vulnerable.

Mostly no. ssh/rsync is compiled C code, so might be slightly faster than a Python-based `wormhole`, if you have a really fast connection to take advantage of. And rsync provides that lovely continue-from-interrupted-transfer feature that magic-wormhole currently lacks.

But wormhole has turned out to be more usable in some cases. I've had days where I'm sshed into a bastion host, then sshed from there into a server, then cd'd into a deep directory with lots of spaces and quotes and shell metacharacters in the path, and then found a file that I wanted to copy out. To do that with ssh, I have to first configure ProxyJump to let me reach the internal machine with a single ssh command, and then figure out how to escape the pathname correctly (which somehow never works for me). With `wormhole send` I get to skip all of that, at the cost of having to do it once per file.

There's a `wormhole send --text BLOB`, which doesn't bother with a bulk-data "transit" connection, and just drops a chunk of text on the receiving side's stdout.

You can also import the wormhole library directly and use its API to run whatever protocol you want. That mode uses the same kinds of codes as the file-sending tool, but with a different "application ID" so they aren't competing for the same short code numbers. https://github.com/magic-wormhole/magic-wormhole/blob/master... has details.

Not really.. the closest approximation would be if both sides set their `--transit-helper` to an unusable port like `tcp:localhost:9`. That would effectively remove the relay helpers from the negotiation list, leaving just the direct connection hints.

But you can't currently force that from one side: if you do that, but the other side doesn't override it too, then you'll both include their relay hint in the list.

Note that using the relay doesn't affect the security of the transfer: there's nothing the relay can do to violate your confidentiality (learn what you're sending) or integrity (cause you to receive something other than what the sender intended). The worst the relay can do is to prevent your transfer from happening entirely, or make it go slowly.

Alas no. It's a one-shot file-transfer tool, and we don't store a copy of the encrypted data or anything. So the sender must stay running until the receiver has finished downloading. If you're comfortable with relying on servers for your security, then I believe wormhole.app offers the clickable zero-install link that you described.

Magic-wormhole can't use that approach, because our security model rules out reliance on servers for confidentiality or integrity. We could safely store ciphertext without violating the model, but you need an interactive protocol with the sender to get the decryption key (otherwise the wormhole code would be a lot larger), so it wouldn't improve the experience very much, and would cost a lot more to operate. The wormhole servers have trivial storage requirements, so the only real costs are bandwidth for the transit relay helper, for when the two sides can't make a direct connection.

None that I know of. It just uses a TCP connection to the mailbox server (with keepalives), and then TCP connections for the bulk-transfer transit phase, so I can't think of anything special that iptables would need to handle it well.

The encrypted connection is used to exchange IP addresses.. maybe you're thinking of the module that e.g. can modify FTP messages to replace the IP addresses with NAT-translated ones? Our encryption layer would prevent that, but we'd probably get more benefit from implementing WebRTC or a more general hole-punching scheme, than by having the kernel be able to fiddle with the addresses.

Yes, it relies on two servers, both of which I run. All connections use the "mailbox server", to exchange short messages, which are used to do the cryptographic negotiation, and then trade instructions like "I want to send you a file, please tell me what IP addresses to try".

Then, to send the bulk data, if the two sides can't establish a direct connection, they fall back to the "transit relay helper" server. You only need that one if both sides are behind NAT.

The client has addresses for both servers baked in, so everything works out-of-the-box, but you can override either one with CLI args or environment variables.

Both sides must use the same mailbox server. But they can use different transit relay helpers, since the helper's address just gets included in the "I want to send you a file" conversation. If I use `--transit-helper tcp:helperA.example.com:1234` and use use `--transit-helper tcp:helperB.example.com:1234`, then we'll both try all of:

* my public IP addresses * your public IP addresses * helperA (after a short delay) * helperB (after a short delay)

and the first one to negotiate successfully will get used.

since otherwise you just scp or rsync or sftp if you don't have the dual barrier

True, but wormhole also means you don't have to set up pubkey ahead of time.

Not yet. The "Dilation" protocol (which is about 80% implemented) is intended to support WebRTC as a transport layer. IIRC it requires a public server to tell you about your external IP address, but magic-wormhole already has a server that could play that role. Once a side learns its own address, it can send it to the peer (via the encrypted tunnel, through the relay server), and then the WebRTC hole-punching protocol tries to make connections to the peer's public address. When both sides do the same thing at the same time, sometimes you can get a direct connection through the NAT boxes.

We don't have that yet, but the two sides attempt direct connections first (to all the private addresses they can find, which will include a public address if they aren't behind NAT). They both wait a couple of seconds before trying the relay, and the first successful negotiation wins, so in most cases it will use a direct connection if at all possible.

scp/rsync are great tools, but they require pre-coordination of keys. One side is the client, the other is the server. The client needs an account on the server machine (so the human on the client machine must provide an ssh pubkey to the human on the server machine, who must be root, and create a new account with `adduser`, and populate the ~/.ssh/authorized_keys file). And the client needs to know the server's correct hostkey to avoid server-impersonation attacks (so the human on the server machine must provide an ssh host pubkey to the human on the client machine, who puts it in their ~/.ssh/known_hosts file).

Once that's established, and assuming that the two machines can reach each other (the server isn't behind a NAT box), then the client can `scp` and `rsync` all they want.

Magic-wormhole doesn't require that coordination phase. The human sending the file runs `wormhole send FILENAME` and the tool prints a code. The human receiving the file runs `wormhole rx CODE`. The two programs handle the rest. You don't need a new account on the receiving machine. The CODE is much much shorter than the two pubkeys that an SSH client/server pair require, short enough that you can yell it across the room, just a number and two words, like "4-purple-sausages". And you only need to send the code in one direction, not both.

Currently, the wormhole programs don't remember anything about the connection they just established: it's one-shot, ephemeral. So if you want to send a second file later, you have to repeat the tell-your-friend-a-code dance (with a new code). We have plans to leverage the first connection into making subsequent ones easier to establish, but no code yet.

Incidentally, `wormhole ssh` is a subcommand to set up the ~/.ssh/authorized_keys file from a wormhole code, which might help get the best of both worlds, at least for repeated transfers.

There are two servers. The "mailbox server" helps with handshakes and metadata transfers, and is super-low bandwidth, a few hundred bytes per connection. The "transit relay helper" is the one that handles the bulk data transfer iff the two sides were unable to establish a direct connection.

I've been meaning to find the time to add NAT-hole-punching for years, but haven't managed it yet. We'd use the mailbox server messages to help the two sides learn about the IP addresses to use. That would increase the percentage of transfers that avoid the relay, but the last I read, something like 20% of peer-pairs would still need the relay, because their NATs are too restrictive.

The relay usage hasn't been expensive enough to worry about, but if it gets more popular, that might change.

Yeah, syncthing is awesome for repeated interaction.. once you've configured the two sides to know about each other, it's really flexible for doing an initial transfer, pushing just the new changes, pushing to multiple destinations, etc.

magic-wormhole doesn't need the initial configuration, but only lets you transfer one file (or one directory). So it's better for ad-hoc transfers, or for safely establishing the configuration data you need for a more long-term tool. The analogy might be that magic-wormhole is to synthing as scp is to rsync.

The snap/flatpak thing is weird, and I share your discomfort with uncertain provenance of software delivered that way.

I wrote the original version in Python, and took advantage of a number of useful dependencies (Twisted, to begin with), but a consequence is that installing it requires a dozen other packages, plus everything that Python itself wants. I've watched multiple people express dismay when they do a `brew install magic-wormhole` and the screen fills with dependencies being downloaded. If I knew Go, or if Rust had existed when I first wrote it, I might have managed to produce a single-file executable, which would be a lot better for deployment/distribution purposes, like wormhole-william provides today.

author here.. happy to answer any questions!

(author here)

The protocol enumerates all the IPv4 addresses on each side, and attempts to connect to all of them, and the first successful handshake wins.

So if your VPN arrangement enables a direct connection, `wormhole send` will use that, which will be faster than going through the relay (and cheaper for the relay operator).

A basic VPN gets you safe connectivity between the two sides, but transferring a file still requires something extra, like a preconfigured ssh/scp account, or a webserver and the recipient running `curl`/`wget`. magic-wormhole is intended make that last part easy, at least for one-off transfers, just `wormhole send FILENAME` on one side, and `wormhole receive [CODE]` on the other.

(magic-wormhole author here)

Thanks for making a donation!

I run the relay server, but the Debian maintainer agreed to bake an alternate hostname into the packaged versions (a CNAME for the same address that the upstream git code uses), so we could change it easily if the cost ever got to be a burden. It hasn't been a problem so far, it moves 10-15 TB per month, but shares a bandwidth pool with other servers I'm renting anyways, so I've only ever had to pay an overage charge once. And TBH if someone made a donation to me, I'd just send it off to Debian anyways.

Every once in a while, somebody moves half a terabyte through it, and then I think I should either move to a slower-but-flat-rate provider, or implement some better rate-limiting code, or finally implement the protocol extension where clients state up front how much data they're going to transfer, and the server can say no. But so far it's never climbed the priority ranking high enough to take action on.

Thanks for using magic wormhole!

Maybe $20/mo. The bandwidth is growing but not too bad so far, every once in a while I see a really huge transfer that makes me wince (seriously, who sustains a gigabit/s for five hours?), but I've still got some margin before I run up against the monthly transfer allowance. When that happens, I'll probably move the server to a provider that has a slower but flat-rate bandwidth plan, maybe Scaleway. Transfers would be capped by their network limit (100Mbit?), but effectively free.

I might also change the transit relay to throttle the connection somewhat after some total number of bytes have been transferred (but that takes actual code, and switching providers would be easier). I'm really glad folks are using it, but I do sort of think that >10GB at a time is a bit much. But I don't have a way to notify a given user about any sort of soft limit like that (the transit relay has no idea how much you're going to send ahead of time, and doesn't have a notification channel other than throwing an error).

I've also been meaning to figure out NAT hole punching for years now, and the thought has always been that hole-punching will save a lot of the server bandwidth by making direct connections happen a larger percentage of the time.

As aborsy said, if you can encrypt ahead of time, that's great, you're only relying upon the server for availability, (just like magic-wormhole). You would not be vulnerable to the Dropbox server, or the folks who run them, or someone who managed to compromise it, or to confuse it into giving your files to them, or.. say, that bug which caused all authentication to just be turned off entirely for four hours in 2011.

But to let your recipient decrypt your pre-encrypted data, you have to communicate your strong (>=128 bit) key to them, as well as enough information to point at the ciphertext (hostname, port, file ID if the server handles more than one at a time). That's a UX challenge, because 128 bits aren't very humane, no matter how you encode them. Dropbox has a feature to let you upload a file and then get a URL you can give to someone else, but it's long and random and hard to read, and still doesn't include any cryptographic protection.

Some secure file-transfer systems deal with this by using fewer bits and then applying a "key stretching" algorithm like bcrypt or Argon2. That forces the attacker to do more work for each guess, which maybe lets you get away with.. 80 bits? 60 bits?. But whoever holds the ciphertext (like the server) can remember it forever, so they can just keep trying for as long as they like, so it's hard to have confidence that you've picked parameters that are strong enough, and the attack resistance is directly at odds with the usability.

Magic-wormhole is using PAKE to bring the necessary cryptographic data down to a safe minimum (16 bits or so), baking in knowledge of a server (plus allocating the shortest distinct file identifier it can, usually just one digit) to minimize the non-cryptographic data, and using a phonetically-distinct wordlist to maximize the usability / transcribability of the whole thing. It lets you say just "use magic-wormhole and the code is 4-purple-sausages" and you're done. But it's a trick, of course: we can only get aware with codes that short by pointing everybody at the same servers. You can easily self-host, but then you must either recite a lot more information to your recipient ("use magic-wormhole with --relay-url=ws://myserver.example.net:4000/v1 and a code of 4-purple-sausages"), or pre-stage that information by giving them a config file ahead of time.

As for the servers, I run them. Their source code is in repos next to that of the client, namely https://github.com/magic-wormhole/magic-wormhole-mailbox-ser... and https://github.com/magic-wormhole/magic-wormhole-transit-rel... . But the client is designed so that you don't have to rely upon the servers or the people running them to still get confidentiality and integrity of your transferred data. Those properties depend just upon the implementation of the client, and of course the computer that you run it on.

The initial low-bandwidth data (a few hundred bytes) goes through the "mailbox server". That phase is store-and-forward, and is used both to perform the PAKE protocol (to get a strong shared key), and to use the now-encrypted connection to negotiate whatever else you want to do (like establish a direct connection for file transfer). The bulk data transfer happens over a direct connection if one can be made, else it goes through the "transit relay", but in neither case does large amounts of data get stored on a server.

This means magic-wormhole lacks an important feature that many of its competitors have: the ability to close your computer before your recipient has finished (or even started) retrieving the data. I decided to use an approach that was more sustainable by me (the servers use just a tiny DB for the store-and-forward part), and leave the features that start to look like a file-hosting service to other projects.

Good question! The code is broken up into two parts: a number, and some words. The number is like a mailbox: you put messages into it, the person you're intending to talk to puts messages into it, (maybe an attacker puts messages into it), everybody can read the messages there.

The words are secret. There's a special cryptographic protocol named PAKE ("Password Authenticated Key Exchange") that tells you what messages to put into the mailbox. The protocol has a lock-step part in the middle, where you don't generate your second message until you've seen the other person's first message (and vice versa).

When the protocol is done, if the two people used the same secret words, they'll wind up with the same secret encryption key, and nobody else will know the key. If they used different words, they'll wind up with random strings. The file transfer uses the shared key to encrypt the bulk data.

Your client will generate a random wormhole code (random words plus server-allocated mailbox number) and run the protocol exactly once. It will generate and send its first message, wait for the partner's first message, then generate and send the second message, wait for the partner's second message, compute the shared key, do a test to see if it matches the other side (send a hash of the key), negotiate a direct connection if possible, then encrypt and transmit the file data.

If an attacker is trying to guess your code, their only option is to pretend to be your intended recipient and follow the same protocol. They watch the server and learn the mailbox number: that part isn't secret. But then, to send their first message, they have to commit to some particular secret words. And they don't get to find out if they were right or not until they see your second message, by which point your client knows that this "one shot" has been used up, and it's either correct (the key-verification hash matches) or it's not (or the attacker disconnects and runs away, in the hopes of getting you to blame a flaky network instead of suspecting an attacker).

If it fails, the client tells you that fact and quits, and you have to re-run the program (getting a brand new random wormhole code) to try again. Which means the attacker is back to square one: they know their first guess was wrong, but now the code is different, so their second guess has exactly the same chances of being right as the first guess.

A few I've found:

* You're sitting next to someone at a conference (remember those?) and want to hand them a file: fewer steps than email, the wormhole code is easier to transcribe than most email addresses, the file lands where you want it to rather than in a spam folder somewhere, and neither of your email providers or the network in between them can snoop on or modify the data in transit.

* You're ssh'ed into a remote machine, via two layers of proxy servers, deep in a directory structure with lots of spaces and quotes and backslashes and other shell metacharacters in the path, and you want to transfer a file from there back to your desktop. You have no idea how to quote everything properly. So you wormhole it to yourself.

* I'm on zoom or the phone with a friend and want to send something from my desktop machine to their laptop. I can read the wormhole code off the sending machine, speak it to them over the phone, they can type it into their machine. The codes are optimized for spoken clarity.

* I'm debugging something on the little computer attached to my television and want to copy a logfile off to a real machine. I've got a terminal window open on the screen, and a shell, but that account doesn't have an email address, nor is it listening on SSH. I could write a python one-liner that listens on an HTTP port, but there's no security to that. I can 'wormhole send LOGFILE' and read the code from the screen, and type it into my laptop.

By "safely" I mean: confidentiality against anything outside your two computers (eavesdropper only learns the length of the data, as is true for most networks), and integrity (nobody in the middle can modify the file, or cause you to receive something different than what your partner sent). The security of most common file transfer methods depends upon some intermediate server, or two, or a dozen (in the case of email).

If by "untrusted computers" you're making a distinction between distributing files to computers that you already know about, vs to computers that you've just met, then yes, that's exactly right. If your laptop and your desktop already know about each other, there are a bunch of tools that work better for a lot of cases, like a shared network filesystem or AirDrop. Magic-wormhole is kinda aimed at how to introduce two machines that don't already have a connection. The wormhole code is a way to leverage the connection between the humans who control those computers, into a secure shared encryption key between the computers themselves.