Great idea, but needs to massively improve its security margin; the current 16-bit margin does mean that any particular use has a 1:65,536 chance of being MITMed, but that means that as people use it the odds of no-one being compromised get exponentially smaller; if 1,024 people use it 16 times ever, then there's only a 78% chance that none of them is MITMed.
The developers should target 128 bits. Yes, this means longer phrases.
edit: Also, it'd be cool if someone were to add this capability (with a sufficiently-strong passphrase mechanism) to OpenSSH, thus making it easier to distribute initial SSH keys.
Yeah, the 16-bit "wormhole code" means that each active MitM attack has a 2^-16 chance of success, and a 1-(2^-16) chance of causing a broken connection. The error message you get (which also happens if someone simply mistypes the code) is:
% wormhole receive-text
Enter receive-text wormhole code: 9-babylon-typo
ERROR:
Key confirmation failed. Either you typed the code wrong, or a would-be
man-in-the-middle attacker guessed incorrectly. You could try again,
giving both you and the attacker another chance.
On average, you should expect to see 32 thousand failures before there's a 50/50 chance of a successful MitM attack. If your transfer attempt fails 10 times in a row, you're probably under a persistent attack, and you should stop using this tool.
Since failed attacks are so visible, I decided that 16 bits was a good tradeoff. Note that you can make it longer: "wormhole --code-length=4" uses 4 words (32 bits), etc. There's also a --verify option that displays a full-strength SHA256 session key hash for comparison, after the PAKE exchange but before transferring any actual data. Finally, since the words are coming from a fixed list, there's tab-completion when you input the codes, which turns out to be really handy.
PAKE codes are single-use, and not subject to offline attacks, so I don't think 128 bits codes are necessary (it'd be a different story if they were hashed directly into encryption keys :-). Incidentally, magic-wormhole uses (my) "python-spake2" library, which implements SPAKE2 (http://www.di.ens.fr/~pointche/Documents/Papers/2005_rsa.pdf) over the Ed25519 elliptic-curve group.
The magic-wormhole python package includes a library to use these codes in other tools: in the long run, I'm hoping to get PAKE more visibility as a "pair two computers together" primitive, and transferring SSH keys would be an awesome use case for that. Also, I'm planning to add a "--persistent" flag of some sort, which records the generated session key somewhere, indexed by a petname, so the second time you want to send someone a file, you just say "wormhole send-file --petname=bob", and you don't have to transcribe a wormhole code at all.
Very different use case. Both of those require that one party know the IP address of the other and is able to make an inbound TCP connection. This seems to be more like a STUN system for creating such a connection.
Well, not "very". If both computers don't see each other you need to either set up a mediator (no matter if scp or this tool), or you need someone else to set up a mediator for you. The first case is more secure, the second case is easier. Getting more secure and easier at the same time is simply not possible.
I think we're talking past each other: this tool is a mediator which uses a low-entropy key seemingly to do both discovery and authentication. The author is running a mediator server.
"Make this system accept inbound scp from the internet and provide discovery" is currently something that requires quite a bit of configuration. It's not really something that I'd want to walk someone through on the phone. Mind you, neither is "install this from github", but it could be rolled into an installer.
There are two useful things (IMHO) in magic-wormhole. The first is the PAKE-based security model, with the invitation codes. The second is the "try to find each other" STUN-fallback transit stuff. Transit is way less interesting than PAKE, but by combining the two, you get a tool that's about as simple as it could possibly get while still being secure.
magic-wormhole always uses a baked-in rendezvous server (which I run) for exchanging PAKE messages, and frequently uses a baked-in transit server (which I also run) for the bulk data of file transfer. If one of the two sides has a public IP address or they're both on the same subnet, the file transfer runs directly, without my transit server. My transit server is effectively a STUN server.
I have a list of alternative approaches to explore (use the BitTorrent DHT, use Tor hidden services, use IP multicast groups, local MDNS, IPFS), which may do one or more of the following:
* reduce the single-point-of-failure -ness
* reduce the exposure of IP addresses
* increase the exposure of IP addresses
* reduce the load on my server
* speed things up
* slow things down
Compared to scp: to get proper (i.e. non-password) security out of ssh/scp (and rsync on top of them), you must have previously copied a public key to the target machine, which requires e.g. reading the string to someone sitting next to you and having them type it in, or publishing the key somewhere that can be reached by something you read to them and then visually comparing what they got with what you meant to publish. (at least for the initial contact; once you've set up the keys, then future transfers are trivially easy). Plus the target must be reachable by TCP.
For magic-wormhole, you still have to read something to them, but it's really short and designed specifically to be transcribed aloud. And the two sides don't need TCP reachability.
I figured that almost every form of file transfer involves either the sender telling some reference string to the recipient (like a URL of some sort), or the recipient telling some destination reference string to the sender (an email address), followed by a bunch of other work that's annoying and reduces security. Magic-wormhole requires the same "read something to the recipient" part, but removes the setup phase, and removes all the security-losing middlemen.
I'm starting to wonder if such things will soon be a lost art by confused kids rummaging through github trying to find out how to do such things readily available on any *nix/BSD computer.
It's so funny how *nix gets rediscovered on a daily basis and only in few cases people actually can improve on tools that are older than their grand parents.
But I can also understand why people do it. At first you need to have this experience that you just spent months building something that actually already exists. And then you still might have a boss and friends who wouldn't give you even 10% of the respect for googling the already existing solution compared to building one yourself (that might not even be usable by other people and therefore making you look even more important to your boss).
This seems similar in concept to pushbullet (http://www.pushbullet.com) which I've been using for a few months and find extremely useful. I'm glad an open source version of that is in the works, I'll keep an eye on this. Keep up the good work!
Author here.. didn't realize this made it to HN yet, I was wondering where the spike in traffic came from :). Sorry to miss the initial questions, but feel free to ask me more.
webRTC is an awesome way for getting data from one web browser to another, but you must bootstrap it by copying a webRTC "offer" message in both directions first. Most of the webRTC-based videochat services (Firefox Hello, talky.io, etc) use a server to deliver the client page and also relay these offer messages to the right party. So ultimately the security depends upon that server deciding to deliver the offer directly, and not inserting itself as a man-in-the-middle.
The PAKE-based wormhole setup would be a great way to get those offers delivered safely. In a future browser-based magic-wormhole.js library, I would use webRTC as the default data-transfer mechanism, and then I wouldn't need to run a STUN-like transit server (at least if you're talking to another browser, or client that can speak webRTC).
The developers should target 128 bits. Yes, this means longer phrases.
edit: Also, it'd be cool if someone were to add this capability (with a sufficiently-strong passphrase mechanism) to OpenSSH, thus making it easier to distribute initial SSH keys.