[tor-dev] Is it possible to leak huge load of data over onions?
dawuud at riseup.net
Mon Apr 4 01:53:18 UTC 2016
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.
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 . 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?
>  http://panamapapers.sueddeutsche.de/articles/56febff0a1bb8d3c3495adf4/
> Happy hacking,
> Ivan Markin
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Digital signature
More information about the tor-dev