Magic-Wormhole – Get things from one computer to another, safely(github.com)
github.com
Magic-Wormhole – Get things from one computer to another, safely
https://github.com/warner/magic-wormhole
191 comments
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.
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.
Why would I use magic worm-hole instead of Syncthing or Signal? They are both user-friendly and easy to install for the person I want to send the file to.
The only shortcomings I can imagine:
_AFAIR Signal has a size limit on the file you can send
_you need a phone number and a smartphone to use Signal
_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to
1) install Signal
2) install Syncthing and share the keys
rather than install magic-wormhole and use some passphrase.
_AFAIR Signal has a size limit on the file you can send
_you need a phone number and a smartphone to use Signal
_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to
1) install Signal
2) install Syncthing and share the keys
rather than install magic-wormhole and use some passphrase.
Signal and Syncthing are great. magic-wormhole is more about setting up that initial connection: when two humans know each other, but their computers haven't met yet (i.e. know each others pubkeys).
In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.
For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.
My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).
In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.
For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.
My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).
Thanks a lot for the reply! Indeed I was thinking that the main use case that would make sense is the integration of your tool in other more complicated protocols, as a simple first step. As you mentioned, the Syncthing "device id" is 56 characters long that are pseudo-random and thus nigh impossible to remember. Having magic-wormhole as a first step in the handshake would make everything easier.
P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.
P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.
> In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code
...and upon third-party rendezvous/relay server, doesn't it?
...and upon third-party rendezvous/relay server, doesn't it?
You don't trust that third-party server with any information, it simply makes the initial link between the two parties, like a DNS, that it needs to send the encrypted information to.
An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.
An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.
You can also fallback to Tox or other existing public P2P network.
You can also use https://ondevice.io for that. But in that case it let's you ssh into the remote device even if it changes location/ip-address.
I use it for some IoT tinkering I do.
> Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account?~
Assuming that you have openssh and rssh installed, you bootstrap like this: useradd -m -g users -s /usr/bin/rssh tmp passwd tmp edit /etc/rssh.conf and uncomment allowscp Share the password with the party you want to exchange data with. Make sure your ports are open.
See: https://serverfault.com/questions/197545/can-non-login-accou...
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted, and extends to cover other use cases much more easily (rsync, VNC, etc.).
Assuming that you have openssh and rssh installed, you bootstrap like this: useradd -m -g users -s /usr/bin/rssh tmp passwd tmp edit /etc/rssh.conf and uncomment allowscp Share the password with the party you want to exchange data with. Make sure your ports are open.
See: https://serverfault.com/questions/197545/can-non-login-accou...
The use case I see for wormhole is if you're working purely in the python ecosystem. That's it.
You're free to disagree of course, but I prefer ssh, since it's peer-to-peer end-to-end encrypted, and extends to cover other use cases much more easily (rsync, VNC, etc.).
Okay.
Step 1. Open ports on your router. It's your job to figure out which ports those may be.
Step 2. Redirect said ports to the box in question, hopefully you'll know the ip address that was assigned by your home router's DHCP
Step 3. Make sure rssh is installed.
Step 4. If rssh is not installed, please simply follow the simple instructions to get it installed for your system.
Step 4a. If it's a mac, use brew. Type brew install rssh
Step 4b. If it'a a redhat system, type yum install rssh
Step 4c. If it's an ubuntu system, type apt-get install rssh
Step 4d. If step 4b and step 4c fail, use sudo.
Step 5. Get the external facing ip address, and give it to your friend. Note that this is different than the internal address that you used in step 2.
Step 6. Create an account on your system, using rssh, and allowing sftp
Step 7. Give him the username/password
Step 8. Copy the file into his account
Step 8a. Don't forget to chmod it so he can read it.
Step 9. Tell him to get the file
Step 10. Remove the account from /etc/passwd and /etc/shadow and remove him from /etc/groups. Also delete his home directory
Step 11. Rejoice in the simplicity.
Step 1. Open ports on your router. It's your job to figure out which ports those may be.
Step 2. Redirect said ports to the box in question, hopefully you'll know the ip address that was assigned by your home router's DHCP
Step 3. Make sure rssh is installed.
Step 4. If rssh is not installed, please simply follow the simple instructions to get it installed for your system.
Step 4a. If it's a mac, use brew. Type brew install rssh
Step 4b. If it'a a redhat system, type yum install rssh
Step 4c. If it's an ubuntu system, type apt-get install rssh
Step 4d. If step 4b and step 4c fail, use sudo.
Step 5. Get the external facing ip address, and give it to your friend. Note that this is different than the internal address that you used in step 2.
Step 6. Create an account on your system, using rssh, and allowing sftp
Step 7. Give him the username/password
Step 8. Copy the file into his account
Step 8a. Don't forget to chmod it so he can read it.
Step 9. Tell him to get the file
Step 10. Remove the account from /etc/passwd and /etc/shadow and remove him from /etc/groups. Also delete his home directory
Step 11. Rejoice in the simplicity.
Instead you get to pip install. But pip isn't installed. easy-install pip? What's easy-install - it's not there? (brew|yum|apt-get) disttools. Forget this... download get_pip.py, run python get_pip.py... Some error about libsodium now? Where do I get gcc for Windows 10 again?
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
Python's greatest weakness is its packaging and distribution, and this project makes no effort to make it simple.
On the mac, you can:
brew install magic-wormhole [1]
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
[1] https://github.com/warner/magic-wormhole
brew install magic-wormhole [1]
And that covers 90% of the people that care. Granted I think you're right that software packaging and distribution is still generally broken in 2017, but that's a problem across the board. It's a problem with java, node.js, python, etc.
[1] https://github.com/warner/magic-wormhole
And that covers 90% of the people that care
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
Disagree. I don't know a single non-programmer with brew installed on their Mac, and non-programmers make up 90% of the people who have the most trouble copying files between two computers.
sysadmin here in MAD world using homebrew since Lion. First thing I did when I got in this morning was to pull out my personal MBP and install magic-wormhole.
And for those people there is dropbox, google drive, etc.
So, this tool is intended for users of macs who are comfortable using a shell and use `brew`, but are not comfortable with `ssh`?
I'm not even sure I see how this is much easier than ssh if you know the basics.
I'm not even sure I see how this is much easier than ssh if you know the basics.
[deleted]
So... 'brew install rssh' is bad and kludgy, but 'brew install magic-wormhole' is easy and light? And hey, if you're not on a mac, you have to also install a bunch of other deps too.
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
You probably shouldn't have tried to pad out your steps by taking a detour into package management.
I'm not gonna argue against that. Using pip-install certainly limits our current audience to people who are comfortable with python packaging tools, which basically means python developers.
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
I'm hoping to get beyond that, once I get the protocol and feature set stabilized. Using something like PyInstaller or py2app to get a single-file executable will be the first step. Porting it to other languages (I've started on SPAKE2 in Rust) might help too.
FWIW, "apt install magic-wormhole" now works on Debian (stretch) and Ubuntu (zesty). Also homebrew, as mentioned before.
Quick survey: what packaged form would be most useful to you (for desktop usage.. having some kind of iOS/Android app is a whole other beast). PPA? .dmg? .exe? .msi?
A stand alone static binary that does not depend on system libraries.
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
Specifically, one that 'just works' on windows, and doesn't require that you open powershell and need to change into an obscure directory to use it, or have the binary sit in a folder full of DLLs to run.
In fact, ideally one you don't have to even type anything in; for example, if you can just say; grab this one file from some safe known url (eg. github), and rename it from 'magic.exe' to 'zesty-fruit-324234.exe' and run it.
FWIW, that's what the Go tools produce by default.
But pip isn't installed.
It's been bundled with Python for years now, and even if you don't have it, it's easy to get:
https://pip.pypa.io/en/latest/installing/
It's been bundled with Python for years now, and even if you don't have it, it's easy to get:
https://pip.pypa.io/en/latest/installing/
This is true but not completely. You will only get pip when you install the binary downloaded from python.org. On osx, people use brew, on Debian, they use apt. It is most likely only Windows people will download those binaries but actually they use Anaconda, WinPython instead
It's still very easy to install. And as of Python 3.4 it's even easier since you can 'python -m ensurepip'.
Why are the packages removing pip?
Anaconda provides its own separate package-management world, so it makes sense that it doesn't include pip. But you can always still install it.
I'm actually getting tired of package managers reinventing the wheel (literally) every time they want to install something.
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
In production when I deploy a django app, now I might have two libraries in different places in my system. One from the OS, and one from the pip dependency.
if only to address the dependency issue, one can rewrite the magic wormhole in go, then do cross-platform compilation and distribute the standalone binaries
UPnP could have helped with the router bits and dynamic DNS could help with the internal/external bits. https://upnp-portmapper.sourceforge.io is fun but UPnP isn't enabled everywhere reliably, and explaining how to do that + ensure it's working is probably only going to work for someone who would know what homebrew is.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
AirDrop is cool in theory but works about 20% of the time for me. In 2017, the best way to send someone a large file is still to upload it somewhere then give them the link to it. https://getdropsha.re and similar stuff makes that easy enough that your non-technical relatives can use it successfully.
Okay.
The equivalents to steps 1-11 were done by the Wormhole authors when they created the rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have to trust the rendezvous server.
Operating scp with a working ssh server is as simple as working with wormhole:
To push:
scp foobar.txt [email protected]: #equivalent to wormhole send
To pull:
scp [email protected]:foobar.txt . #equivalent to wormhole receive
To revoke access, you simply change the password, instead of deleting the user account. In fact, the steps you mention are what I already have by default on most of my machines, so there's 0% extra effort. I got rssh working in five minutes.
Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.
Compare explaining the above two commands to explaining virtualenv and pip. On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also preinstalled on their system.
So yes, I do rejoice in the simplicity.
I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.
The equivalents to steps 1-11 were done by the Wormhole authors when they created the rendezvous server. So yes, if you use Wormhole in SaaS mode, it's simpler, but you have to trust the rendezvous server.
Operating scp with a working ssh server is as simple as working with wormhole:
To push:
scp foobar.txt [email protected]: #equivalent to wormhole send
To pull:
scp [email protected]:foobar.txt . #equivalent to wormhole receive
To revoke access, you simply change the password, instead of deleting the user account. In fact, the steps you mention are what I already have by default on most of my machines, so there's 0% extra effort. I got rssh working in five minutes.
Steps 10/11 are my responsibility, and the only remaining step for the other developer is step 7.
Compare explaining the above two commands to explaining virtualenv and pip. On a busy public IRC channel, I'm not going to do that, I'll use scp, since it's also preinstalled on their system.
So yes, I do rejoice in the simplicity.
I commented for the benefit of those already running ssh, and who wondered how to create a similar setup to wormhole with what they have. rssh will work fine.
> but you have to trust the rendezvous server.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.
Do you? It seems that magic-wormhole does end-to-end encryption, and the rendezvous server acts only as a relay if one or both parties are behind NAT. So yes, you leak the two parties' IP addresses, but not the files you transfer.
You have no way to verify that the rendezvous server you're connecting to isn't playing the role of the client or server.
That doesn't make sense. The client needs the passcode to read the file, and that passcode is sent out of band. The Relay server can't simply "play the role of the client" and steal the file.
Of course, you're right. I was thinking the rendezvous server generated the key. Thanks for the correction.
You forgot "Step 4a.1" Go to brew.sh and follow the instructions to install brew.
> you bootstrap like this
Ah, yes. oh come on please it's easy just /etc/init.apt-get/frob-set-conf --arc=0 - +/lib/syn.${SETDCONPATH}.so.4.2 even my grandma can do that
Ah, yes. oh come on please it's easy just /etc/init.apt-get/frob-set-conf --arc=0 - +/lib/syn.${SETDCONPATH}.so.4.2 even my grandma can do that
I would like to highlight the quality of the satire in your comment.
[deleted]
When both parties are in a corp network (eg across companies) you would need a server anyway. Many either offer a FTP server or have switched to Accellion (which is kinda cr.p, and full of security holes)... so this is a nice, fast and secure alternative.
Surprised no-one has mentioned socat ('netcat on steroids') in this context, which is what I use to quickly transfer files, especially in closed network contexts.
And Dropbox is just an FTP server with SVN.
You can use ssh/scp in pure Python (e.g., StaSh on Pythonista for iOS provides scp/ssh commands).
[deleted]
I would highly recommend looking into this (seemingly-obscure) technique for NAT hole punching: https://samy.pl/pwnat/
It would allow for a "magic wormhole"-style system without the need for a MITM (trusted or otherwise).
It would allow for a "magic wormhole"-style system without the need for a MITM (trusted or otherwise).
Both pwnat and chownat are very clever techniques, but I have massive doubts they work _well_ in practice, when exposed to hundreds (or even dozens) of popular NAT devices and network configurations.
Vast majority of NAT boxes change the source port on outbound packets even if a respective externally-facing port is not yet allocated. Anything that's BSD derived will randomize the port, lots and lots of others will +1 the port for each new session, thirds will +2 the port, etc.
There's also egress filtering, intrusion detection systems and NAT devices that do things that make little sense such as remapping ID field in the IP header, presumably for security reasons. Also, depending on the OS, this will need root privileges to craft fake ICMP packets.
All in all, pwnat/chownat are essentially very cool "tech demos" that can't be realistically used just on their own and require a conventional rendezvous server as a fallback.
Vast majority of NAT boxes change the source port on outbound packets even if a respective externally-facing port is not yet allocated. Anything that's BSD derived will randomize the port, lots and lots of others will +1 the port for each new session, thirds will +2 the port, etc.
There's also egress filtering, intrusion detection systems and NAT devices that do things that make little sense such as remapping ID field in the IP header, presumably for security reasons. Also, depending on the OS, this will need root privileges to craft fake ICMP packets.
All in all, pwnat/chownat are essentially very cool "tech demos" that can't be realistically used just on their own and require a conventional rendezvous server as a fallback.
Yeah these are excellent points. I think the biggest blocker is definitely the symmetric NAT case, since this would still be a problem even if both sides already knew the public IP of the other end...
I wonder if there is still some opportunity to find workarounds in this space. I did see some papers on prediction of the external ports based on local port and NAT vendor, but this is obviously not going to work for a no-bs-magic-wormhole-style solution.
I wonder if there is still some opportunity to find workarounds in this space. I did see some papers on prediction of the external ports based on local port and NAT vendor, but this is obviously not going to work for a no-bs-magic-wormhole-style solution.
That's cute. But will it work if you have two sessions behind the same NAT trying to use it?
How likely is it that something like that trick makes IDS go crazy?
Probably moderate with this specific technique, but I imagine you could use some simpler method where each end of the transfer is willing to share their public IP. This would reduce the problem to UDP hole punching/scanning across some pre-defined port range and then running whatever traffic you need through that pipe. I feel like this would look less "suspicious" to an IDS than crafting odd-looking ICMP packets.
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 transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
* 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 transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address).
In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.
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?
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.
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.
If you're willing to go the webrtc route for the transport, you might as well look into webtorreny that does everything for you already.
Uh... just an idea: can you leverage the cloud flare infra challenge for the transit server piece?
Why the downvotes? ncp is really useful for hacker space like environments.
I like using https://file.pizza/ for this.
Also https://instant.io/
I like this one but it becomes truly ardous to copy a magnet from one computer to the other. file.pizza at least uses easily pronounceable hashes.
What I would to see from this is a JS which serves every asset on a site via webtorrent so visitors are sharing the bandwidth costs.
What I would to see from this is a JS which serves every asset on a site via webtorrent so visitors are sharing the bandwidth costs.
I prefer https://www.justbeamit.com/
OK I will try to remember this one, it's neat, "dba9q" is not too horrible, a plane ticket PNR is worse.
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).
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.
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.
Call me a nerdy hipster, but I prefer my 1-in-2^256 chance with AES encryption. Then I can put it, well, anywhere. Including a thumb drive, google drive, S3, email, or even some random public newsgroup.
I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.
I realize this complicates things a touch - you need a program to encrypt and decrypt the file - but that seems much more secure.
You also need to read the full AES key to your recipient. If you've already got a secure channel to your recipient, great: you can just paste them the key. But if you're sitting next to a new friend at a conference and want to throw them a copy of your secret file without worrying about who else might be able to see it in the future, you might want something more.. ergonomic :).
Your odds probably aren't that good.
https://www.schneier.com/blog/archives/2011/08/new_attack_on...
Close though :)
https://www.schneier.com/blog/archives/2011/08/new_attack_on...
Close though :)
[deleted]
> a --verify option, which causes the program to print out a hex hash of the session key
This is plenty enough.
Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.
This is plenty enough.
Another option is to use the ssh model whereby the sender has a persistent keypair, uses it to sign the handshake and sends the pub key to the peer. If the peer has this key in its key cache, it proceeds quietly. Otherwise it pops up a "New key, please verify and approve" message before proceeding.
Isn't it more like a <number of pending transfers>-out-of-65536 chance of getting it right? If there are 256 pending transfers, then it's more of a 1 in 256 chance of stealing someone's information?
The more popular this program gets, the easier it is to steal people's information?
The more popular this program gets, the easier it is to steal people's information?
Does the session key hash help if the attacker guessed the code correctly?
Yup, it still does. In the face of a lucky-guessing attacker, PAKE basically degenerates down into plain unauthenticated Diffie-Hellman, which means Alice-Mallory has one key, and Mallory-Bob has a different key. Mallory could decrypt the messages from Alice and then reencrypt them for Bob, but Alice and Bob will still both see different keys. If they have some out-of-band means to compare those keys (which Mallory can't corrupt), then they can detect the attack.
Thanks!
[deleted]
More people should use Keybase, and this would be more easier within its filesystem https://keybase.io/docs/kbfs
Eh,I like the concept of kbfs and have it installed on my PC and phone, but it's not really a competitor to this. Keybase reminds me of a secure alternative to Dropbox or Google drive. You've got a quota that you can upload to their server (encrypted). While you can use it to move files between destinations, that isn't it's primary goal.
And it's not a lossless storage at that, as their filesystem doesn't support all metadata . I.e. it removes any timestamps from the files.
And it's not a lossless storage at that, as their filesystem doesn't support all metadata . I.e. it removes any timestamps from the files.
I see you guys arguing what is easier, wormhole, syncthing, ssh. I'll argue that Keybase is by far the easiest. Just but the files in /Keybase/private/person0,person2
I love Keybase.. they're doing great things to bind public keys to names at large identity providers (twitter, github, etc). And in many cases, the github username of your intended recipient is the only thing you know about them anyways.
magic-wormhole can help you in the case where you're sitting next to someone at a conference and they don't have a github/twitter account, or if you want don't want to depend on github/twitter/etc access control (e.g. if some bug in github allowed gists to be published under other people's usernames, that aspect of the keybase security story would fail).
It might also appeal to folks who don't care for centralized identity providers. When we worked on Mozilla Persona, we tried to make it possible for individuals to run their own IdPs and "own your own identity". Keybase can sorta do that (by proving ownership of an HTTP or HTTPS URL), but magic-wormhole is "better" in the sense that it doesn't have any concept of identity at all. The file goes-to/comes-from the person who knew the same code, end of story.
I'm interested in some sort of combination: maybe a confirmation step that uses a wormhole code to exchange the expected public keys with a Keybase peer, to make sure they're the same, without needing to type or read the full RSA key. (There's a protocol named SAS, "Short Authenticated Strings", that can be useful in this case).
magic-wormhole can help you in the case where you're sitting next to someone at a conference and they don't have a github/twitter account, or if you want don't want to depend on github/twitter/etc access control (e.g. if some bug in github allowed gists to be published under other people's usernames, that aspect of the keybase security story would fail).
It might also appeal to folks who don't care for centralized identity providers. When we worked on Mozilla Persona, we tried to make it possible for individuals to run their own IdPs and "own your own identity". Keybase can sorta do that (by proving ownership of an HTTP or HTTPS URL), but magic-wormhole is "better" in the sense that it doesn't have any concept of identity at all. The file goes-to/comes-from the person who knew the same code, end of story.
I'm interested in some sort of combination: maybe a confirmation step that uses a wormhole code to exchange the expected public keys with a Keybase peer, to make sure they're the same, without needing to type or read the full RSA key. (There's a protocol named SAS, "Short Authenticated Strings", that can be useful in this case).
> Copying files onto a USB stick requires physical proximity, and is uncomfortable for transferring long-term secrets because flash memory is hard to erase. Copying files with ssh/scp is fine, but requires previous arrangements and an account on the target machine, and how do you bootstrap the account? Copying files through email first requires transcribing an email address in the opposite direction
I had similar motivations in 2006 to write a tool to copy files "point to point". So here's my shameless plug:
https://bitbucket.org/etanol/canute
In my case, cryptography was not a requirement, though.
I had similar motivations in 2006 to write a tool to copy files "point to point". So here's my shameless plug:
https://bitbucket.org/etanol/canute
In my case, cryptography was not a requirement, though.
Waiting for the security nits, but this looks awesome and I have use cases for it every week
Ditto. This would be very useful if it were available on all platforms (Android, OIS, Rpi)!
A similar LAN or virtual network oriented tool:
https://github.com/zerotier/toss
... and another less magical one:
http://www.fefe.de/ncp/
https://github.com/zerotier/toss
... and another less magical one:
http://www.fefe.de/ncp/
Interesting to see the various approaches. I've been using a pair of simple scripts myself for ages:
https://github.com/pflanze/chj-bin/blob/master/netoffer https://github.com/pflanze/chj-bin/blob/master/netfetch
(they use a few other scripts from the same repo) used like follows (only practical when being able to copy-paste, my use case is to copy things between servers without needing ssh authentication between them, but having open ssh sessions into both from the same desktop/laptop):
https://github.com/pflanze/chj-bin/blob/master/netoffer https://github.com/pflanze/chj-bin/blob/master/netfetch
(they use a few other scripts from the same repo) used like follows (only practical when being able to copy-paste, my use case is to copy things between servers without needing ssh authentication between them, but having open ssh sessions into both from the same desktop/laptop):
chris@a:/tmp/chris$ echo Hello > World
chris@a:/tmp/chris$ netoffer World
--Run:--
echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ echo jxqtrb7xfq2e4dqy3uitc7986ydj56w59iqu84b | netfetch 78.47.51.206 15123
chris@b:/tmp/chris$ cat World
Hello
I'm surprised https://datproject.org/ didn't come up already.
It also allows you to share any data but also deals with incremental updates. The main use-case is to share big scientific datasets that update over time.
It also allows you to share any data but also deals with incremental updates. The main use-case is to share big scientific datasets that update over time.
Also, Piknik: https://github.com/jedisct1/piknik
My life is so much happier with Windows. Accessing files on any computer is very easy. Wannacry and that other nasty worm prove it to the world. :)
Didn't catch any malware or viruses since the 90s on my Windows. Copying files with a few mouse clicks is much more comfortable and fast then this...
Cool. Does the data transit the server, or does it do NAT / UPNP type stuff for direct comms after the initial rendezvous?
The two sides exchange IP addresses (inside the encrypted channel), and try to connect to all of them. If that fails to produce a successful handshake, they fall back to a "Transit Relay Server" that I run. So they'll manage a direct connection if one of the machines has a public IP address, or if they're both on the same LAN.
I'm hoping to add NAT/UPnP support, but it's not there yet.. still looking for an easy library with Python support.
I'm hoping to add NAT/UPnP support, but it's not there yet.. still looking for an easy library with Python support.
What happens when your transit server's bandwidth bill gets out of hand because someone is transferring a few TB of data to their backup host? (see article a few days back about someone griping about their 13 TB backups on Backblaze if you aren't sure this is a real thing)
It'll probably just break for the remainder of that month. I'm hosting that transit server on Linode, and I think (does anyone know for sure?) that their policy is to just turn off the interface if you go over your monthly allowance, which is like 4TB or 6TB on that instance.
Eventually I'm planning to have the client ask the transit server ahead of time for the size it intends to use, and the server can tell them to go away or make a donation or something.
"wormhole --transit-helper=tcp:HOST:PORT send" is how you can use a different server: the sender will tell the receiver about it in-band, so the receiver doesn't need to do anything special. The receiver accepts that argument too.
Eventually I'm planning to have the client ask the transit server ahead of time for the size it intends to use, and the server can tell them to go away or make a donation or something.
"wormhole --transit-helper=tcp:HOST:PORT send" is how you can use a different server: the sender will tell the receiver about it in-band, so the receiver doesn't need to do anything special. The receiver accepts that argument too.
[deleted]
He will probably shut it down. The server is in the source code.
This kind of tool should probably be distributed as a binary but then it would be a bit harder to know it doesn't do anything strange.
I would probably write it in go to make it easy to compile for different platforms.
I would probably write it in go to make it easy to compile for different platforms.
https://transfer.sh/ is another neat service which allows you to upload a file easily using a tool such as curl and get a shareable link. There was one time when I only had Chrome Remote Desktop access to a machine without root, where this was a convenient way to share some files.
$ curl --upload-file ./hello.txt https://transfer.sh/hello.txt
https://transfer.sh/66nb8/hello.txtIn a similar vein[1], using the python client:
[1] https://www.thregr.org/~wavexx/software/dl/ [2] https://fex.rus.uni-stuttgart.de/
$ dl-cli some/files
https://dl.example.com/t=<hash>
[1] https://www.thregr.org/~wavexx/software/dl/ [2] https://fex.rus.uni-stuttgart.de/
http://termbin.com/ is very cool too, especially if you have nothing but netcat.
$ < hello.txt nc termbin.com 9999
http://termbin.com/e51kWhy not use one of the online peer-to-peer file transfer services:
https://send-anywhere.com
https://takeafile.com
https://www.justbeamit.com
https://www.sharedrop.io
https://www.reep.io
https://send-anywhere.com
https://takeafile.com
https://www.justbeamit.com
https://www.sharedrop.io
https://www.reep.io
Discussed in 2015: https://news.ycombinator.com/item?id=9953767.
How is the 16 bit wormhole code secure against brute force?
Any attacker only gets a single guess
What if there are 65535 active send requests? Perhaps of which 65534 are opened by an attacker?
The attacker still just gets 1 guess per wormhole / send request. Each send-request / wormhole is its own separate thing.
I'm still unclear on a couple of things. How do you even know which send request the attacker attempted to attack if only the codeword identifies the send request, and the codeword was wrong? Also, what stops an attacker from trying again - alternatively, what stops an attacker from doing a denial-of-service by purposefully guessing the wrong codeword?
The codes have a small number in front; these are the requests. So if the server did allow 65k requests, each one would be a different number. You can guess once per request.
Yes, an attacker can denial-of-service by guessing once on all the (possible) requests. There is some work towards stopping this sort of behavior (see e.g. https://github.com/warner/magic-wormhole/issues/126)
Yes, an attacker can denial-of-service by guessing once on all the (possible) requests. There is some work towards stopping this sort of behavior (see e.g. https://github.com/warner/magic-wormhole/issues/126)
Thanks for the explanation!
Probably all "slots" would be "occupied" and everybody gets the attacker's sent file, iiuc.
Or the attacker only needs to monitor the last free slot to see what shows up?
Seems to work both ways. Receive random file from unknown people or send chosen file to unknown people?
EDIT: was just explained in other comment by meejah, thanks! (https://news.ycombinator.com/item?id=14649727#14650551)
EDIT: was just explained in other comment by meejah, thanks! (https://news.ycombinator.com/item?id=14649727#14650551)
This would be so much more useful it was written in a language that made it easy to distribute the whole thing as a single statically compiled binary.
See also https://www.sharedrop.io/ (WebRTC-based AirDrop clone)
Great collection of tools here. I'm adding here my own approach, aimed at getting around proxies/firewalls:
the files are encrypted and sent in the body of a HTTP request. The receiving end is a simple nodejs http server that can be started on the fly.
https://github.com/mihaifm/getransfer
https://github.com/mihaifm/getransfer
So, basically, scp (with a 16-bit session key that has to be exchanged oob)?
Yeah, if you've already gotten a public key set up (and an account on the target machine), then scp is much easier and completely secure. magic-wormhole is more aimed at situations where you don't yet have that pubkey copied over. Or where your receipient doesn't want to give you an entire account just to receive a single file.
In fact there's a mode (kinda experimental right now) to use magic-wormhole to transfer an ssh pubkey into the ~/.ssh/authorized_keys on a new account. Ideally your site admin should be able to give you access to a new machine with a wormhole code, instead of having you email them a pubkey.
In fact there's a mode (kinda experimental right now) to use magic-wormhole to transfer an ssh pubkey into the ~/.ssh/authorized_keys on a new account. Ideally your site admin should be able to give you access to a new machine with a wormhole code, instead of having you email them a pubkey.
scp requires additional network routing config to get it past a NAT, which is most residential internet.
or, like, netcat? `nc -l -p 8888 > foo` to listen, `nc 10.10.10.1 8888 < tail -500 /dev/random` to send.
Still cool though :)
Still cool though :)
yup, except with netcat:
* the network-side attacker gets to see and modify all your data * the receiver must have a public IP address * the receiver must tell something to the sender, which is the opposite of the direction the data will flow * you have to transcribe your IP address and port number to the other person, which I always get wrong (so many meaningless numbers!) * you don't get much confirmation that all the data arrived, or that it arrived accurately
The wormhole code uses a wordlist that was carefully designed (not by me.. I'm using the PGP wordlist, as used by PGPfone and Zfone) for accurate spoken transcription in noisy environments. So it's more likely that they'll type in the right thing.
* the network-side attacker gets to see and modify all your data * the receiver must have a public IP address * the receiver must tell something to the sender, which is the opposite of the direction the data will flow * you have to transcribe your IP address and port number to the other person, which I always get wrong (so many meaningless numbers!) * you don't get much confirmation that all the data arrived, or that it arrived accurately
The wormhole code uses a wordlist that was carefully designed (not by me.. I'm using the PGP wordlist, as used by PGPfone and Zfone) for accurate spoken transcription in noisy environments. So it's more likely that they'll type in the right thing.
That's awesome :)
Users may also want to look into NitroShare. Although it only works on the local network, it uses IP broadcast for automatic peer discovery (next version will use mDNS). It includes installers for Windows and macOS. Debian, Ubuntu, and Fedora include it in their respective package archives. There is also an Android app. (Disclaimer: I am the maintainer.)
Extending this to a small text-based GUI with chat could make it a lot more useful, too. Sort of like a person-to-person BBS.
> The receiving side offers tab-completion on the codewords...
Nice.
Nice.
Anybody know how the author generated the word-list? I generated one for my own passphrase use; I took the 2000 most common english words and used metaphone to prune any similar sounding words, which got me down to around 600; I then truncated the list to 512 yielding 9 bits per word.
It is the PGP Word List: https://en.wikipedia.org/wiki/PGP_Words
Looks like another application the key exchanges algorithms used in Mozilla Weave/Firefox Sync. They used to do that to associate new devices and send them the keys, but they killed that because the UX was more complex than user/password.
Interesting. How does this compare to WebRTC based peer-to-peer file transfer like perhaps https://simplewebrtc.com/filetransfer as an example?
Hey everyone! I just did a quick video on Magic Wormhole showing how it works: https://www.youtube.com/watch?v=1SXCLAlpD70
Hey everyone! I just did a quick video on Magic Wormhole showing how it works: https://www.youtube.com/watch?v=1SXCLAlpD70
How does this compare to AirDrop (besides obviously being cross platform)?
AirDrop: waaaay better UI, awesome animated drag-and-drop, dead-simple to use, works offline. Not so strong at clearly identifying who the file came from or is going to. Not clear what sort of integrity/confidentiality properties you get (probably better than nothing, knowing Apple, but since the send-to-which-device picker UI shows their self-selected names, there's not any obvious way to distinguish between the real "Alice's iPhone" sitting next to you and the attacker who's within bluetooth range.
Magic-Wormhole: CLI only (so far), no OS integration anywhere, better security properties. Also it's got a spiffy wizard-hat logo (thanks Katie!).
Magic-Wormhole: CLI only (so far), no OS integration anywhere, better security properties. Also it's got a spiffy wizard-hat logo (thanks Katie!).
It operates over the Internet instead of Wi-Fi / Bluetooth and it initializes transfers by a code.
Some of the golang folks are working on a very interesting project.
https://github.com/upspin/upspin
https://github.com/upspin/upspin
This is so handy. I pushed it to the snap store. So if you're on a snap supported Linux distro you can just run "snap install wormhole" to get it and future updates.
There are some handy docker images for this over on the docker hub if you want to try them and dont have/want the needed python setup but just happen to have docker installed
I don't know why you're getting downvoted, sharing files is still in an abysmal state. This wheel will be reinvented again.
Make mine pushbullet. Love it.
https://www.pushbullet.com/
Seems likely the use of the "Rendezvous" term is going to get you a cease-and-desist just like Apple got over what is now known as "Bonjour" (aka mDNS)
https://en.wikipedia.org/wiki/Bonjour_(software)
https://en.wikipedia.org/wiki/Bonjour_(software)
RNDZ, and RV are two well understood abbreviations :)
Strictly for internal networks, and no crypto in transit, but dead easy - also for grandma - and covering phones as well as the three pc platforms: Dukto. I use it all the time.
http://www.msec.it/blog/?page_id=11
http://www.msec.it/blog/?page_id=11
I just use socat or netcat on home networks. Pipeview for a progress meter. I am as paranoid as they come, but if someone has my small home network they already have my data :)
When I want to give things, I use ssh to put it in the static part of my website in a directory with a random name, then I send the url by mail. My sftp client is already configured with ssh keys. When the things I have to send is a collection of jpeg files, I use fgallery.
"My sftp client is already configured with ssh keys." Well, one of the use cases is "how do you get the SSH pubkeys from here to there?"
My point is that everybody should have a website somewhere (my C1 at cloudscale is 3.59€ per month). Everybody should have a ftp client configured to access it without hassles.
Everybody? That's a very brave idea. As in "non-techies are non-people," or "everybody should become a techie"?
(Also, FTP is an insecure, broken, incomplete, horrible, ancient protocol that should have died in a fire 20 years ago; never mind that I may want to transfer files between two people, not hang those files out onto the web)
(Also, FTP is an insecure, broken, incomplete, horrible, ancient protocol that should have died in a fire 20 years ago; never mind that I may want to transfer files between two people, not hang those files out onto the web)
[deleted]
the motivations are great:
"Moving a file to a friend's machine, when the humans can speak to each other (directly) but the computers cannot
Delivering a properly-random password to a new user via the phone
Supplying an SSH public key for future login use"
i had never even thought about those, and this is a great solution afaik
"Moving a file to a friend's machine, when the humans can speak to each other (directly) but the computers cannot
Delivering a properly-random password to a new user via the phone
Supplying an SSH public key for future login use"
i had never even thought about those, and this is a great solution afaik
> Supplying an SSH public key for future login use
It's public so it can be emailed in cleartext to the admin of the server, copied in any instant messenger or painted on walls. It's the secret key that ensures all the security of the connection.
It's public so it can be emailed in cleartext to the admin of the server, copied in any instant messenger or painted on walls. It's the secret key that ensures all the security of the connection.
It still needs to be authenticated. It could be replaced by an attacker public key.
This is a scenario where "the humans can speak to each other (directly) but the computers cannot". Key authenticity is not a problem, the other party can verify that the fingerprint is correct.
True, but have you actually tried to verify even a short SSH pubkey over a human communication channel? It can be done, but the horrible, horrible UX!
Trusting the baked-in rendezvous server would seem to be the most obvious security "nit," which could be addressed by compiling and running your own server. But out-of-the-box, that would seem to be a weak-point for MitM attack.
[deleted]
Not exactly the same, but for those Linux/KDE users who look for a tool to connect to another machine within the same LAN, I can recommend KDE-Connect (file-transfer, notifications, shared-clipboard, etc.).
> The wormhole library requires a "Rendezvous Server": a simple WebSocket-based relay that delivers messages from one client to another.
[deleted]
[deleted]
Nice, 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-...
http://techcrunch.com/2017/06/27/magic-wormhole-is-a-clever-...
I expected something local, like airdrop, but cross platform. (someone, please)
Sounds like Dukto: http://www.msec.it/blog/?page_id=11
Supports Windows (XP and up), OS X/macOS (10.6 and up), Linux (packages for Ububtu and Fedora), and Symbian. Ports available for iOS, Blackberry, and more.
Supports Windows (XP and up), OS X/macOS (10.6 and up), Linux (packages for Ububtu and Fedora), and Symbian. Ports available for iOS, Blackberry, and more.
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.
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?
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?
Since it's a public key, how about via unencrypted email?
Even then, the email would need to be signed and verified to ensure the key wasn't modified. You wouldn't want an attacker replacing it with their own public key.
But you would want tab completion of the shared secret so all an attacker needs is to guess the first character?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
Why not email the ssh public key in plaintext and verify the md5sum, sha1sum, fingerprint, and / or first and last X characters of the key itself over the phone?
... or... Why not just put the public key on a web server with SSL and a free cert and speak the URL, then scp the payload file over? Or go ahead and get the free S/MIME cert from Comodo for your email since you can sign without the other end sending a signed email first and attach the payload file itself or an ssh public key and then scp? Or use Pidgin or a similar client with the OTR plugin on any XMPP server and send the payload file in the first place? Or issue SSL keys from your own local CA and communicate the fingerprint orally? Or send the public ssh key plaintext and only allow ssh through the firewall from the IP of your friend?
... or ... allow ssh via password rather than key for a small timeframe and communicate a password out of band rather than a shared secret for this thing?
... or ... put your ssh public key on a well-known account of yours like GitHub, Facebook, HN, etc and let your friend install it from there?
Very true, I'd personally never use the tab completion since the secrets are short enough, and I will probably raise an issue on the project to have that be optional.
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!
And for the rest, they're still a hassle compared to just having your hackerspace friend install magic-wormhole so you can toy around with the nonsense he has on his Raspberry Pi.
Your last point, however, I think will be the key to the future (no pun intended). I'm hoping asymmetric crypto based communication will become easy, ubiquitous, and the default. Cheers to Keybase!
I often use pastebin.
Interesting. Would it be possible to use it on Android and IOS?
Very simple, handy, and yet powerful utility. Thanks.
Cool, seems like AirDrop which I find very useful.
why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/