Hi.
My general feeling here is that it's more useful for me to tell you how I think people should share files than it would be for me to answer your questions; sorry, not sorry.
Alice and Bob can share lots of files and they can do so with their Tor onion services. They should be able to exchange files without requiring them to be online at the same time. Are you sure you've choosen the right model for file sharing?
If you want reliability then you should desire to not have single points of failure such as a single Tor circuit or a single onion service; further, the high availability property might be important for certain types of file sharing situations.
If Alice and Bob share a confidential, authenticated communications channel then they can use that to exchange key material and secret connection information. That should be enough to bootstrap the exchange of large amounts of documents:
- Alice is clueful about distributed content-addressable ciphertext storage so she decides to operate a Tahoe-LAFS storage grid over onion services. - Alice uploads her ciphertext to the tahoe grid. - Alice sends Bob the secret grid connection information and cryptographic capability to read her files.
In this situation Alice really doesn't care where her storage nodes are hosted and if the virtual server hosting provider can be depended on to not get hacked or receive a national security letter. Why does Alice give zero fucks? ciphertext. "They" have her ciphertext and it's useless without a key compromise. Anyone who hacks the storage servers she is operating gets to see some interesting and useful metadata such as the size of the files and what time they are read; not nearly as bad as a total loss in confidentiality.
https://gnunet.org/sites/default/files/lafs.pdf
However what if Alice decides that Bob is a useless human being and she should instead publicize the documents herself? She writes her own badass adversary resistent distributed ciphertext storage system and convinces several organizations world wide to operate storage servers in various countries and thus several legal jurisdictions.
She can now gleefully upload ciphertext via onions services to the storage servers and then simply publicize the key material for specific files she wishes to share with the world or an individual. She can make this system censorship resistant by utilizing an erasure encoding for storing the ciphertext. For instance Tahoe-LAFS uses Reed Solomon encoding such that any K of N shares can be used to construct the ciphertext of the file. In this case if an adversary wanted to censor Alice's ciphertext publication they would have to DOS-attack N-K+1 servers.
Recently someone leaked enormous amount of docs (2.6 TiB) to the journalists [1]. It's still hard to do such thing even over plain old Internet. Highly possible that these docs were transfered on a physical hard drive despite doing so is really *risky*.
No that's not necessarily correct; if the drives contain ciphertext and the key was not compromised then the situation would not be risky.
Anyways, in the framework of anonymous whistleblowing, i.e. SecureDrop and Tor specifically it's seems to be an interesting case. I'm wondering about the following aspects:
o Even if we use exit mode/non-anonymous onions (RSOS) is such leaking reliable? The primary issue here is time of transmission. It's much longer than any time period we have in Tor. o What is going to happen with the connection after the HS republishes its descriptor? Long after? [This one is probably fine if we are not using IPs, but...] o Most importantly, is transferring data on >1 TiB scale (or just transferring data for days) safe at all? At least the source should not change their location/RP/circuits. Or need to pack all this stuff into chunks and send them separately. It's not obvious how it can be done properly. So at what point the source should stop the transmission (size/time/etc)/change location or the guard/ pick new RP?-- [1] http://panamapapers.sueddeutsche.de/articles/56febff0a1bb8d3c3495adf4/ -- Happy hacking, Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev