4 ms·

How does it compare to rsync? Or scp? (scp is at least mentioned)

by erikb 11y ago

pjc50 11y ago
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 11y ago
  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 11y ago
    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.
- lotharrr 11y ago
  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.
justwannasing 11y ago
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.
- erikb 11y ago
  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).

How does it compare to rsync? Or scp? (scp is at least mentioned)

by erikb 11y ago

How does it compare to rsync? Or scp? (scp is at least mentioned)

pjc50 11y ago

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 11y ago
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 11y ago
  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.
lotharrr 11y ago
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.

justwannasing 11y ago

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.

erikb 11y ago
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).