Sorry for the top reply; my mobile email client's capabilities are lacking.
Yes. This category of attack is a thing. It sounds similar to a (flawed) law enforcement attack described in a paper dated 2013 that leaked a while back: https://www.reddit.com/r/Freenet/comments/4ebw9w/more_information_on_law_enforcements_freenet/ The site providing it has since been password protected, but the reaction remains. Do I understand your countermeasure proposal correctly: for each file, probabilistically choose a peer to route all requests for it? Interesting! It would of course worsen routing, but maybe not too much. IIRC routing is more a function of link length distribution than individual misrouting. I worry that because a single node cannot accept as many requests files could alternate between current and worse performance. The temptation would be to hide it behind some higher network security level, but this kind of thing is only useful if it's the default. Do we know whether a peer can evaluate HTL distribution, or location distribution of blocks known to be in a file, or something to guess whether probabilistic decrement is in use? That would be my concern about tying it to the same decision. Other than that I like this proposal! -------- Original Message -------- On Apr 12, 2017, 12:25 PM, Stefanie Roos wrote: > Hi, > > we are currently looking into different methods for censorship-resistant > publication in distributed systems using different replication techniques. > > I have a question regarding the anonymity of downloaded a file that is > split in a reasonable large number of blocks. Are the requests for all > blocks forwarded independently using FoF routing (or the hill-climbing > algorithm if FoF is disabled). > > If so, doesn't that enable the following attack: Assume an adversary > wants to find out if one of her peers is downloading the file. She can > obtain the manifest file and thus the CHK keys of all blocks. Someone > downloading the file will request all blocks, forwarding the requests to > different peers. These will forward the request to their peers. So > likely their peers will receive more block requests than non-peers. So, > if the adversary wants to find out if she is connected to the requester, > shouldn't receiving a high number of requests for the different blocks > of the same file be a really good indicator that this peer is the actual > requester and not only forwarding? The math is a bit more complicated, > as the the number of files per peer will not be uniform. Nodes have few > peers at a large distance and those have a higher chance of being the > closest peer to a CHK block (or have the closest peer to a key if FoF > routing is enabled). Nevertheless, I think this is clearly a serious > problem, if I understand what is happening correctly. > > Wouldn't it be better to add the possibility of forwarding all block > requests along the same link initially? It could be tied to the > probabilistic HTL decrease: Initiator/forwarder with HTL=18 of a request > uses random peer. If HTLDecrement==false is set for that connection, all > block requests are forwarded to that peer (or rather one request > including the manifest file), otherwise all of them are routed > individually as it is now (if that is what is happening now). Now, the > adversary can use the above attack to tell which peer started routing > rather than random forwarding but that might not be the requester. > > Any thoughts on that? > > Thanks, > > Stef > -- Stefanie Roos Postdoctoral Fellow CrySP, University of Waterloo https://cs.uwaterloo.ca/~sroos/
