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:
> >Okay. What exactly were the proposed bad solutions? I don't see why > >there would be a problem if either of my endorsed suggestions were > >implemented: > >a) Pcache as normal for local requests. Have a separate client level > >cache, encrypted with per-node-session keys. > >OR > >b) Implement premix routing. Don't send local requests through local > >datastore AT ALL. Have a separate client level cache as above. > The proposed bad solutions were: > > >SOLUTION #1: that the the node itself would flag any keys that the > >operator has requested as "requested only by me". Then, if the node was > >asked later for a key that held such a flag, it would pretend that it > >didn't have it, search for the key on other nodes, and then reset the > >key's flag if it found it on another node. That flag would of course be invalidated if we had a parallel request from another node for that file etc... > > >SOLUTION #2: that keys that we request would somehow be moved into a > >separate, encrypted store, and never placed in the main datastore. I do not support that. We must do the caching normally, if the requests are made normally. And then have a separate cache of stuff requested locally at a higher level. So it may be cached in the DS, if pcaching says it needs to be. Of course, if we implement premix routing, we would not either read or write the datastore for local requests, and no node would know they came from us. > > In short, each one tries to pretend that it never requested the keys it > in fact requested by passing queries for them along to other nodes > rather then replying with the data at hand. It must cache it anyway for all to see if pcaching says so. Otherwise locally requested content is detectable by its absence. > > Let's make sure we're on the same page. I was in complete agreement > with you when you said: > > >The attack we are talking about in this > >thread though, is also pretty hard to secure against - if we download all > >the pieces of the splitfile, and cache them in the user-cache, we will > >also cache some of them in the datastore, because of pcaching doing its > >normal thing. One solution proposed was to not cache content downloaded > >by the local user in the local datastore at all, or only if it is > >fetched by another node. The problem with that is that if the node we > >route to sees us fetching a key and then queries us for that key and > >finds we don't have it (through a timing attack - fixing the key > >presence timing attacks will be a pig and cost lots of performance IMHO, > >so we have to think carefully about it), it KNOWS that the user > >requested the key. Well, with pcaching, it doesn't KNOW, but it knows > >there is a certain chance that the user requested it, and if it > >correlates a large number of pieces from a single large site or > >splitfile, it can get a pretty good idea that you requested that site or > >splitfile... there may or may not be the possibility that there is a > >node with a degenerate routing table routing all its requests to your > >node which actually asked for it, that is one possible defence. Anyway, > >my suggestion: implement premix routing for all local requests; the > >first node you route to knows you but does not know the key; the second > >knows the first and knows the key but does not know you, and then routes > >the key and returns the data through the chain. Of course we may want > >the chain to be longer than that. Anyway, once premix routing is > >implemented, we can then not cache locally requested content at all in > >the datastore, because it goes a completely different route, and nobody > >knows we requested it so nobody can check whether we have it. That is > >probably the answer to a lot of these attacks. But the key probing > >attack still remains, and it's a question of how much we care about the > >ability for a node to effectively ask your node whether it has a given > >key in its store - how much of a vulnerability is that? > > 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. > > >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. > > -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
