Free App Lets the Next Snowden Send Big Files Securely and Anonymously
wired.com
wired.com
Both of the users have to be online simultaneously; both will be sending/receiving roughly the same amounts of data at roughly the same time.
If the user is under observation already (due to suspicion, or due to being on a logged network), and the recipient is already under monitoring (a safe assumption if he's a well known journalist writing about NSA, or Wikileaks, or whatever), it's pretty easy to correlate the flows, then find/fix/finish.
The less insane way to do this is to publish an encrypted file to some pool (usenet, youtube, etc.) using whatever anonymity technology is available to you, and then at some point in the future have the recipient download it. Moving a 256bit key anonymously can be done much more safely through the control channel (the same way you tell the user where to download), and could even be done in a broadcast way.
Or, USPS. There, you get first class mail protection on the contents, an easy to understand security model, and limited user education. I'd use USPS in preference to the SecureDrop system, and I'd sure use it in preference to this.
Am I missing something, or is this part just an advert for the book? I doubt the office's staff technologist/security_guy first heard about Greenwald's tech security problem from his book.
With regard to the technology itself, it looks like this just uses Tor for the file store without ever solving the hard problem: negotiating with the other party. The tough problem here isn't hosting a file; we don't need Tor for that. I could just as easily encrypt a file and serve it up with https://github.com/mikegrb/App-otfile. The tough part is getting a key securely to my friend around the world, without being MITMed or having our communication recorded and decrypted.
Having looked at the code, I'm kind of alarmed by a few things. It appears to need to run as root to manipulate iptables, and doesn't appear to drop privileges. It also doesn't use file encryption, it relies on basic auth, and it's serving over HTTP, so the creds and then the file go across the wire unencrypted.
Edit: Also, bundling a bunch of related libraries in doesn't seem like a good idea. A user either has to audit all of them for changes from the upstream source or trust that this repo faithfully tracks updates without making modifications.
I think it would be more sensible as a matter of defense in depth to not rely on Tor's transport encryption for this purpose. I guess it's a fairly steep challenge for UI, though, because you currently can't get a CA to issue a certificate for a .onion name (although there is a remote possibility that this could change if the P2P TLD RFC is adopted and then the CA/Browser Forum agrees to recognize the P2P TLDs as legitimate subject DNS names in certs).
They provide the recipient with the URL and password for
that site, preferably via a message encrypted with a tool
like PGP or Off-The-Record encrypted instant messaging.
Put the cipher text on a Pirate Bay torrent for all it matters, the problem reduces down to sharing the key.
Stock Tor is only 1024-bit RSA as I recall, so if you're relying on that alone to encrypt the documents over the network you've already left the door open for well funded attackers.
So your recipient would be the only person to download a file of some specific size at some specific time, from a service that only ever served it once. Traffic analysis is how the Tor network is attacked in practice. Unfortunately, Onionshare is more vulnerable to traffic analysis than even the old GnuPG and Dropbox method.