On Thu, Oct 16, 2003 at 04:22:20PM +0200, Some Guy wrote: > --- 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/
Thanks. IP layer anonymization is really cool, in the unlikely event that it can be constructed without major weaknesses. > > In my belief the hardest thing in P2P isn't request/poster anonymity, but storer > annoymity. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
