--- Martin Stone Davis <[EMAIL PROTECTED]> wrote: > Some Guy wrote: > > 1) For your own personal requests your node could cache at 100% in a special cache > > which isn't > > used to handle other people's requests, but pcache your own requests in the public > > one just > like > > normal. > > > > This opens you up to securtiy issues, if your drive is compromised, but these > > could be dealt > with > > "loopback crypto" or an extension of fred which would ensure the stores contents > > would be lost > if > > the machine looses power (or maybe require a passphrase to restart). > > > Given that my local store allocation is large enough that pcacheing has > not been triggered, is this any different from my solution #1 (which I > discredited)? Even if the drive is not compromised, it suffers from the > same problem that solution #2 suffers, as I showed in my hypothetical. Sure, but it helps. Right now if you go to the same site a few times in the same day and your browser doesn't cache, you'll download the thing a couple times if pcaching has kicked in. That's just dumb. It hurts performance and increases the data available to those adversaries.
> > 2) There's an ongoing arguement about maybe caching with a higher probablity > > things in your > spec. > > This may protect against some timing attacks since: > > a) I'll have reason to request and cache such data anyway, if it's in my spec. > > b) I'll have an excuse to throw away such data quickly if it's outside my spec. > > > Not sure how that works exactly, but again, if my store allocation is so > large that my pcacheing is nowhere near being triggered, wouldn't that > be no different from what we have today? Maybe I completely > misunderstand what you are saying here. Please explain. Wait until your cache is full before doing anything "bad". A months GBs of data in your store should help you out. > > 3) Don't run such "SLUTY" nodes that do it with everyone. If you connect only to > > people you > have > > real trust in and they do the same, you'll be pretty safe. Of coarse doing this > > is some work, > and > > one mole could compromise his neighbors. > > > > Freenet's topology must be like a random graph or small world; this is thought to > > be true of > > social networks which should give rise to such trust based nets. However, that's > > all theory > and > > no practice as far as I know. > > > Hmm. Interesting. But how do you build "real trust" in a way that > neither the RIAA nor AAIR could fake trustworthiness? >From life. Get some friends, get them to run freenet and link to you. You might >give trust to people within your university and link to them. Get all your fellow revolutionaries in AAIR to form cells and interconnect them, minimizing the posible damage a mole can do. If you form a random graph or small world freenet should magically figuar out how to route in it. Trust like this can backfire if your friends are more likely to screw you than a random guy. It definately can leave you open to some trafic analysis. "Fearless Leader, this man is rebel and his computer consistantly talks to these. Let's snuff out all the people from the 1st and 2nd order neighbors to be safe." > > 4) Inserter/requestor anonymity can be improved with another layer of onion style > > routing. > For > > example I pick n nodes, I build a chain up only talking to the first one. Each > > node gets a > > symetric key and the last node acts as my proxy for insertion an deletion. In > > order for them > to > > link it to me all n nodes have to be compromised. > > > > You can improve this buy making a few of these chains and using each one for a > > particular > peice of > > hashspace and connecting them to nodes which might be specailized in the area (or > > let them > become > > so). > > > > I believe Toad mentioned doing this for maybe just two hops or so. > > > Yes, that would certainly strengthen inserter/requestor anonymity at the > time of insertion/requesting, but doesn't it still allow for probing the > DS? Yes, but your DS (or at least your public one) would have no relation to what you had surfed. Weaknesses are still timing and traffic analysis. These can be overcome with padding, some random traffic, and maybe some reording and batching. There is also a possible DNS attack where some ass builds a really long chain and pumps through data wasting n times the bandwidth to cripple the system. You can fight this with hash cash and other nice stuff. Lots of people are playing with the stuff. The most ambitious one I've seen works on the IP layer. It was formerly know as Tarzan. http://www.pdos.lcs.mit.edu/tarzan/ In my belief the hardest thing in P2P isn't request/poster anonymity, but storer annoymity. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
