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.
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.
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).
[+] [-] wtbob|10 years ago|reply
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.
[+] [-] lotharrr|10 years ago|reply
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.
[+] [-] erikb|10 years ago|reply
[+] [-] pjc50|10 years ago|reply
[+] [-] justwannasing|10 years ago|reply
[+] [-] dreen|10 years ago|reply
[+] [-] lotharrr|10 years ago|reply
[+] [-] espes|10 years ago|reply
[+] [-] JupiterMoon|10 years ago|reply
[+] [-] lotharrr|10 years ago|reply
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).
[+] [-] nudpiedo|10 years ago|reply
But wormhole sounds cool.