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)
Yeah surface mounts aren't bad. Combined switch and Wifi is good.
Seems like for discoverability you'd have to mount it backward or upside down somewhere so that people can see the ports, and then what about the wifi signal? I see what you mean.
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.
> a "simple URL" isn't big enough to hold a full-entropy encryption key.
I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?).
The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden under some setting on the page, since it’s the sender who needs to understand the implications.
> the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
That’s exactly what I’m looking for. Whenever I need one of these services, there is 0% chance the person on the other side would know how (or have the patience) to install a command-line tool.
> I'm the author of magic-wormhole
Thank you for taking the time to expand so thoroughly from experience.
> One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key.
If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)
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 :).
An attack on the PAKE would involve the attacker seeing the secret value as it was transferred to the recipient and then beating the recipient to the handshake. So there is security value in being prompt in putting in the secret value at the receiving end.
That is as opposed to sending a public key or key fingerprint. In that case there would be little value to the attacker in seeing the transfer. They would have to MITM the transfer of the key itself. If you wanted to prevent the attacker from sending bogus files you would also have to transfer some sort of signing key.
So a short, time limited, secret vs a longer public value.
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.
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.
It's actually possible via https://winden.app which uses the wormhole protocol (compared to wormhole.app which is not affiliated with the matic wormhole project), once you upload a file there it will show you a link which is basically winden.app/#passphrase
As it uses the anchor tag # the passphrase doesn't even get sent to the server hosting the website, so it all happens client side.
