
Get things from one computer to another, safely - adulau
https://github.com/warner/magic-wormhole
======
wtbob
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.

~~~
lotharrr
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](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
How does it compare to rsync? Or scp? (scp is at least mentioned)

~~~
pjc50
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.

~~~
erikb
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.

~~~
pjc50
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.

------
dreen
This seems similar in concept to pushbullet
([http://www.pushbullet.com](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!

------
lotharrr
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.

------
espes
See also:
[https://github.com/mafintosh/webcat](https://github.com/mafintosh/webcat)

------
JupiterMoon
How does this compare to using webRTC?

~~~
lotharrr
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).

