Thanks. Sorry, bit late in answering
>> -------- Original Message -------- >> Subject: Re: manifest files and forwarding >> Local Time: April 12, 2017 11:48 PM >> UTC Time: April 13, 2017 3:48 AM >> From: st...@asksteved.com >> To: devl@freenetproject.org >> >> 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! Essentially yes, in the same random but deterministic manner that the htl is decreased or not. It would likely require one extra hop or less per request, depending on how exactly it is done. >> 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 < >> stefanie.r...@uwaterloo.ca> 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/ >> > -- Stefanie Roos Postdoctoral Fellow CrySP, University of Waterloo https://cs.uwaterloo.ca/~sroos/
