Discussed in 2015: https://news.ycombinator.com/item?id=9953767.
Magic-Wormhole – Get things from one computer to another, safely
31–40 of 192 posts
Re: Magic-Wormhole – Get things from one computer to another, safely
#32Cool. Does the data transit the server, or does it do NAT / UPNP type stuff for direct comms after the initial rendezvous?
Re: Magic-Wormhole – Get things from one computer to another, safely
#33Nice, this looks useful and extensible! I popped it up on TC, I like the idea of transferring files wizard-style.
http://techcrunch.com/2017/06/27/magic-wormhole-is-a-clever-...
Re: Magic-Wormhole – Get things from one computer to another, safely
#34How does this compare to AirDrop (besides obviously being cross platform)?
Re: Magic-Wormhole – Get things from one computer to another, safely
#35Earlier quoted context omitted.
Nifty.. I'll look at the network side of that, maybe we can steal some ideas. At the moment magic-wormhole depends upon one of: * at least one side has a public IP address * both sides are on the same (private) LAN * a TURN-like "Transit Relay" server that I run That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own tra…
If I remember correctly, ncp only works on LANs (using local segment broadcast), so it doesn't require either side to have any Internet connectivity at all. Your approach would be a lot more flexible, but I bet people would also appreciate it if you could figure out a LAN-only mode -- for better privacy, and when the Internet connection is down. Maybe you could start with an ncp-style segment broadcast and then fall…
Yeah, also the two sides can exchange (encrypted) notes about their apparent network environment (including their public IP address, as reported by the rendezvous server), which might give them a clue that they're on the same LAN.
Also see https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.
Re: Magic-Wormhole – Get things from one computer to another, safely
#36Re: Magic-Wormhole – Get things from one computer to another, safely
#37Re: Magic-Wormhole – Get things from one computer to another, safely
#38The security model here is pretty great assuming you trust the rendezvous server. Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
[deleted]
Re: Magic-Wormhole – Get things from one computer to another, safely
#39> The wormhole library requires a "Rendezvous Server": a simple WebSocket-based relay that delivers messages from one client to another. This allows the wormhole codes to omit IP addresses and port numbers. The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support. why not make use of https://docs.syncthing.net/users/st…
Interesting.. I'll take a look at it. My first thought is that magic-wormhole needs a canonical way to allocate "nameplates" (the numeric channel identifier at the start of the wormhole code), and that's tricky to do in a DHT (I'm assuming syncthing's relay server behaves like a DHT). We've got a ticket open ( https://github.com/warner/magic-wormhole/issues/72 ) about distributing this rendezvous server.. I'll add a…
Re: Magic-Wormhole – Get things from one computer to another, safely
#40The security model here is pretty great assuming you trust the rendezvous server. Maybe consider an optional challenge/response prompt (like when your pal enters the prompt code, their client generates a second code that they give back to you) to make sure nobody's intercepted the request before them, odds aside (if someone got your initial code somehow, they could definitely man in the middle the request otherwise).
If I did things right, the rendezvous server shouldn't get any advantage over a network attacker: one guess per invocation of the program, 1-out-of-65536 chance of getting it right, 65535-out-of-65536 chance of giving you a WrongPasswordError.
FWIW, there's also a --verify option, which causes the program to print out a hex hash of the session key, and wait for you to approve it before sending anything. Not as ergonomic, but it removes the MitM threat pretty effectively.