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.)
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).
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.
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.
So, if I don't change my mind, I guess this issue is closed. Now, get back to work! ;)
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
