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. 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
signature.asc
Description: PGP signature