Live data from Hacker News

Magic-Wormhole – Get things from one computer to another, safely

github.com

21–30 of 192 posts

Re: Magic-Wormhole – Get things from one computer to another, safely

#24
> 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/strelaysrv.html ? lots of servers http://relays.syncthing.net/

Re: Magic-Wormhole – Get things from one computer to another, safely

#25
post #5

This reminds me of the great tool http://www.fefe.de/ncp/ , which seems like the same thing only without the cryptographic authentication!

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 back to the transit relay server if nothing on the segment answers and begins negotiation?

Re: Magic-Wormhole – Get things from one computer to another, safely

#26
post #24

> 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 note to check out syncthing.

Re: Magic-Wormhole – Get things from one computer to another, safely

#28
The 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).

Re: Magic-Wormhole – Get things from one computer to another, safely

#29
post #14

What's wrong with S/MIME? Email doesn't have to be unencrypted. Also, you only need to send the public part of an SSH key to the remote end to set up future keyed connections to that system. This seems like a solution with very narrow problems to solve.

Ok, I'll bite. From the project page: "Copying files through email first requires transcribing an email address in the opposite direction, and is even worse for secrets, because email is unencrypted. Copying files through encrypted email requires bootstrapping a GPG key as well as an email address."

And S/MIME is essentially PGP/GPG, except you bootstrap the key from a central Certificate Authority. So yes, it's still a hassle.

As for SSH, how would /you/ place the public key on /their/ remote end? That's a bit of a chicken and the egg problem right there, don't you think?

Post reply on HN