On Thu, Oct 16, 2003 at 09:20:08AM -0700, Martin Stone Davis wrote: > Toad wrote: > > >On Thu, Oct 16, 2003 at 08:13:26AM -0700, Martin Stone Davis wrote: > > > >>Toad wrote: > >>>On Thu, Oct 16, 2003 at 07:45:24AM -0700, Martin Stone Davis wrote: > >>But I didn't think that your endorsed suggestions a) and b) above > >>addressed this attack. Am I wrong about that? OTOH, My solution #3 > >>(reproduced below) IS specifically designed to thwart that attack. > > > > > >Not precisely no, see above. > > D'oh. I think I get it now. You already stated that with premix > routing we can not store all locally-requested data and get away with it > since no one knows that our node requested that data. It sounds like > that solves the problem! (I think you agree that the premix routing > solution is better than the pcaching + encrypted-client-level-cache > solution.)
We CAN get away with a local, encrypted cache because with premix routing it doesn't go through the store. > > As for the possible vulnerability of a node being able to probe our > datastore for a given key, I actually regard that as not much of a > concern: We can easily hold that we didn't request the data...the only > way to hold such an accusation up would be to outlaw freenet...which > they can do anyway until freenet starts using steganography (way in the > future). Right. > > > > >>>SOLUTION #3: Instead, say E queries D queries C queries B queries A. > >>>Even though B doesn't know about D, he is (somehow) able to prove to A > >>>that D is further up in the chain. (Let's leave how that all is > >>>possible for further discussion. I'm just trying to work out the basic > >>>idea here.) > >>> > >>>Now, A can decide whether to REALLY trust B (in which case he checks his > >>>datastore for the key and replies if he has it, or if he doesn't have > >>>it, he routes as usual to another node) or NOT trust B (in which case he > >>>simply routes to another node). His decision on whether to trust B is > >>>based on A's knowledge of B and D. If B and D had routed through each > >>>other too many times in the past, then A will suspect B and D of being > >>>in cahoots (like B and C of my AAIR hypothetical). However, if A sees > >>>that B hasn't had much experience with D, then A will trust B. > > > > > >Hrrm. How does B generate trust? Also, we DONT want to include a list of > >nodes the request has passed through, it gives far too much data to an > >attacker... Anyway I am interested but unconvinced on this one. > This is kind of a moot point since I think I agree with you that the > solution is unnecessary given that Premix routing does the trick. But > anyway: B is initially held as trustworthy. We only stop trusting B if > it teams up with a single other node too often. Also, node B SOMEHOW > doesn't know that node D is up in the chain and SOMEHOW A is able to > figure out that D IS up the chain. I left the SOMEHOW as an > implementation detail ;) ... Anyway it's REALLY MOOT... so let's not > worry about it so long as premix routing solves the problem. Ahh. I see. So it can be mapped to trusted routing only with introductions then. We route to trusted hosts, we get traffic from trusted hosts. We also accept traffic from nodes that prevent a trust certificate from the trusted hosts, or something like that... > > So, if I don't change my mind, I guess this issue is closed. Now, get > back to work! ;) :) > > -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
