-------- Original Message -------- On May 3, 2017, 3:16 AM, Arne Babenhauserheide < arne_...@web.de> wrote:
Stefanie Roos <stefanie.r...@uwaterloo.ca> writes: > Thanks. > > Sorry, bit late in answering I documented an easier to implement version of your idea as note in https://freenet.mantishub.io/view.php?id=3640#c12321 (0003640: Bundles (unencrypted tunnels)) The difference is that it bundles based on the source peer and mixes in local requests (routing by peer only uses information we have at routing time). This is the note I added — does it fit your proposal well enough? - For each source peer for which we do not decrement HTL18, select a target peer at random to whom we forward all HTL18 requests of the source peer. - Mix all our local requests with those of one of the source peers, selected at random. This approach should defeat attacks based on the distribution of requests for chunks from known files in the requests of a given node. If looking only at request distribution, yes, but there are still request rates to consider. Files that aren't all routed to a single peer have higher request rates because the node can use all its peers. (We'd also need to make sure to have rate limits to impair distinguishing a bundle-receiver from a non-bundling requester through request rate. Which is another performance hit.) It introduces a new vulnerability as well: the only time an attacker can expect to receive a bundle - requests for all blocks in a large file - is when connected to the source of the request, and that gives all-but-certainty that the connected node is the requester. I guess this ends up being a numbers game? Currently I think long links are more liable to exceed a uniform share because they cover more of the location space, and those are 30% of the links. [0] This would maintain that problem, but for 50% of files (or whatever it ends up being) one peer has the potential to gain all-but-certain knowledge of what is being fetched. This means attacker certainty for 1/(peer count) for half the files fetched. Is that an improvement for the alternative of 30% of connections suspicion for all files that still applies when not bundling? [0] https://github.com/freenet/fred/blob/build01478/src/freenet/node/OpennetManager.java#L98 possible drawbacks: - disconnecting during the fetch would restart all the non-finished blocks on another peer. Therefore local requests would have increased latency, and strongly increased jitter in latency (losing the wrong peer during transfer would require restarting all non-finished requests) - The anonymity set *with complete knowledge* (which might be attainable via timing attacks by selective DoSing of your peers, one by one or grouped) is just about 2-3 against one of the nodes (the number of HTL18 hops). There is one node for which capturing packets from you means, that there’s a 30-50% probability that you’re the originator. However for all other nodes none of your traffic goes through them — you’re merely forwarding. So the actual probability that you’re the originator of any captured stream of randomly sorted request keys is only 6-10% (with 5 peers for whom you do not decrement HTL). - A small subset of these bundles might propagate very far (in a network of 1000 nodes, the average result for the longest forwarding should be 10 hops, in a network of 16000 14 hops, and so on as log2(N)), so peers might have to replace a target if the latency for the bundled requests is very high (this will limit the maximum length of the forwarding). I’m not sure if our existing connection dropping conditions will fire here (due to timeouts or a too small success rate). Churn should also limit the length of the tunnels: If the average session uptime of a peer is 2 hours, a 10 hops forwarding should typically be broken within 12 minutes while a 2 hops forwarking should live for one hour. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
