Much fewer steps/harder to screw up the process and expose yourself. The ideal would be a "one-click" fully anonymous sharing of sensitive information.
I find it hard to take this seriously... Talking about the Tor Hidden Service;
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.
The hidden service URL (basically, the public key) is not secret. Sharing the URL with PGP would just serve to link your identity to the service, if "they" were ever able to decrypt that, which defeats the entire point of using Tor.
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.
"Micah Lee, the staff technologist and resident crypto expert at Greenwald’s investigative news site The Intercept. ... After reading about Greenwald’s file transfer problem in Greenwald’s new book, "
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.
In the specific case of Tor hidden services, using HTTP has been considered quasi-OK because the Tor hidden service protocol encrypts (using Tor's own transport encryption) through to the hidden service endpoint. That is, the HTTP is actually sent via the loopback interface from the Tor client on the hidden server to the actual application process running on the same host. Thus, virtually all hidden websites have used the http URL scheme with the .onion address.
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).
Sending big files (inherently an asynchronous thing) through a small network which is inherently connection oriented seems like a bad idea. It is a useful tool based on what components are available right now, but this is the wrong way to do things overall for security.
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.
"As soon as the person has downloaded the file, you can just cancel the web server and the file is no longer accessible to anyone," Lee says.
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.
12 comments
[ 4.5 ms ] story [ 43.7 ms ] threadPut 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.
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.
https://github.com/micahflee/onionshare
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).
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.
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.