|
As aborsy said, if you can encrypt ahead of time, that's great, you're only relying upon the server for availability, (just like magic-wormhole). You would not be vulnerable to the Dropbox server, or the folks who run them, or someone who managed to compromise it, or to confuse it into giving your files to them, or.. say, that bug which caused all authentication to just be turned off entirely for four hours in 2011. But to let your recipient decrypt your pre-encrypted data, you have to communicate your strong (>=128 bit) key to them, as well as enough information to point at the ciphertext (hostname, port, file ID if the server handles more than one at a time). That's a UX challenge, because 128 bits aren't very humane, no matter how you encode them. Dropbox has a feature to let you upload a file and then get a URL you can give to someone else, but it's long and random and hard to read, and still doesn't include any cryptographic protection. Some secure file-transfer systems deal with this by using fewer bits and then applying a "key stretching" algorithm like bcrypt or Argon2. That forces the attacker to do more work for each guess, which maybe lets you get away with.. 80 bits? 60 bits?. But whoever holds the ciphertext (like the server) can remember it forever, so they can just keep trying for as long as they like, so it's hard to have confidence that you've picked parameters that are strong enough, and the attack resistance is directly at odds with the usability. Magic-wormhole is using PAKE to bring the necessary cryptographic data down to a safe minimum (16 bits or so), baking in knowledge of a server (plus allocating the shortest distinct file identifier it can, usually just one digit) to minimize the non-cryptographic data, and using a phonetically-distinct wordlist to maximize the usability / transcribability of the whole thing. It lets you say just "use magic-wormhole and the code is 4-purple-sausages" and you're done. But it's a trick, of course: we can only get aware with codes that short by pointing everybody at the same servers. You can easily self-host, but then you must either recite a lot more information to your recipient ("use magic-wormhole with --relay-url=ws://myserver.example.net:4000/v1 and a code of 4-purple-sausages"), or pre-stage that information by giving them a config file ahead of time. As for the servers, I run them. Their source code is in repos next to that of the client, namely https://github.com/magic-wormhole/magic-wormhole-mailbox-ser... and https://github.com/magic-wormhole/magic-wormhole-transit-rel... . But the client is designed so that you don't have to rely upon the servers or the people running them to still get confidentiality and integrity of your transferred data. Those properties depend just upon the implementation of the client, and of course the computer that you run it on. The initial low-bandwidth data (a few hundred bytes) goes through the "mailbox server". That phase is store-and-forward, and is used both to perform the PAKE protocol (to get a strong shared key), and to use the now-encrypted connection to negotiate whatever else you want to do (like establish a direct connection for file transfer). The bulk data transfer happens over a direct connection if one can be made, else it goes through the "transit relay", but in neither case does large amounts of data get stored on a server. This means magic-wormhole lacks an important feature that many of its competitors have: the ability to close your computer before your recipient has finished (or even started) retrieving the data. I decided to use an approach that was more sustainable by me (the servers use just a tiny DB for the store-and-forward part), and leave the features that start to look like a file-hosting service to other projects. |