On Thu, Oct 16, 2003 at 05:10:39AM -0700, Martin Stone Davis wrote: > Some Guy wrote: > > > --- Martin Stone Davis <[EMAIL PROTECTED]> wrote: > ><big snip> > > > >>I'm having a lot of trouble coming up with a good solution. Thoughts? > > > > > >Here are some: > > > >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.
I'm not sure how your "problem" works - the requests will be distributed across the keyspace and unless they can reconstruct your exact estimators they will find it impossible to know anything about exact keys - and even then it'll be a complete bastard, I'm not sure it's even possible. However a proof of concept would be VERY interesting. > > >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. Well, if you are caching everything, then you are vulnerable to the key probing attack - use a timing attack to determine which keys are in the store, and if all the keys in a correlated group (a page, a splitfile) are there, you PROBABLY (you might just be routing for another node that doesn't know any better nodes than you) fetched them. But EVEN WITH PCACHING ENABLED, you can do similar statistical attacks. > > >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? Freenet routing has always relied on path folding, i.e. nodes passing on references of other nodes. A static set of nodes to route to will probably be a major performance hit. > > >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? No, because we could then make the keys locally requested not go through the store AT ALL. We would have a separate cache of course. > > > > > > >Yes Brandon is right; we need to focus on getting the system working well > >first. But this is good > >stuff to think about. > Agreed. > > -Martin -- 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
