Umm, please read the presentation on 0.7. Specializations are simply fixed numbers in 0.7. The problem with probabilistic caching according to specialization is that we need to deal with both very small networks and very large networks. How do we sort this out? Also we need to have an element of LRU, because otherwise nothing will ever be dropped. So we have LRU for deletion, and something to decide whether or not to cache in the first place.
The problem with local requests is quite simply the Register attack. In other words, if we cache everything, and the store isn't full, and maybe even if it is, then once they have seized your store they can see what you have been browsing. On Wed, Nov 30, 2005 at 02:51:59PM +0000, Gordan Bobic wrote: > How about simply encourage specialisation, and cache only according to that? > > On insertion, every node (0-th or n-th hop, all the same) caches the > content, depending on how near it's specialisation it is. Each not > should have only one specialisation, IMO. If that is insufficient, the > one specialisation should broaden and shift, but there should be only > one peak in the key space concentration. > > Each node should figure always be aware of it's current specialisation. > As keys get cached and dropped, this will change, but the node must be > aware of it. The further the key is from the node's specialisation, the > less likely it should be to get cached. > > If each node specialises, the routing should improve, and so will the > deniability. The policy of never caching local requests seems crazy. > They should be treated the same as any other requests WRT caching. > > Everything else seems to be an unnecessary complication with benefits > that are at best academic. > > Node specialisation should arise by design, not by coincidence. > > Just MHO. > > Gordan > > Matthew Toseland wrote: > > Two possible caching policies for 0.7: > 1. Cache everything, including locally requested files. > PRO: Attacker cannot distinguish your local requests from your passed-on > requests. > CON: He can however probe your datastore (either remotely or if it is > seized). (the Register attack) > BETTER FOR: Opennet. > 2. Don't cache locally requested files at all. (Best with client-cache). > PRO: Attacker gains no information on your local requests from your store. > PRO: Useful option for debugging, even if not on in production. > CON: If neighbours then request the file, and don't find it, they know > for sure it's local. > BETTER FOR: Darknet. But depends on how much you trust your peers. > > Interesting tradeoff. Unacceptable really. > > We all know that the long term solution is to implement premix routing, > but that is definitely not going to happen in 0.7.0. > > So here are some possibilities: > > 1. For the first say 3 hops, the data is routed as normal, but is not > cached. This is determined by a flag on the request, which is randomly > turned off with a probability of 33%. > PRO: Provides some plausible deniability even on darknet. > CON: Doesn't work at all on really small darknets, so will need to be > turned off manually on such. > > 2. Permanent, random routed tunnels for the first few hops. So, requests > initially go down the node's current tunnel. This is routed through a > few, randomly chosen (on each hop, so no premix), nodes. The tunnel is > changed infrequently. A node may have several tunnels, for performance, > but it will generally reduce your anonymity to send correlated requests > down different tunnels. > PRO: More plausible deniability; some level of defence against > correlation attacks even. But anon set is still relatively small. > CON: Number of tunnels performance/anonymity tradeoff. > CON: A few extra hops. > CON: Sometimes will get bad tunnels. > > Anyway, this seems best to me. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051130/2d95ec56/attachment.pgp>
