On Thu, Oct 16, 2003 at 07:45:24AM -0700, Martin Stone Davis wrote: > Toad wrote: > > >On Thu, Oct 16, 2003 at 07:11:04AM -0700, Martin Stone Davis wrote: > > > >>Toad wrote: > >> > >> > >>>On Wed, Oct 15, 2003 at 06:14:21PM -0700, Martin Stone Davis wrote: > >>> > >> > >><snip> > >> > >>>>Say that over a long period of time, node A requests keys K1-K1000 from > >>>>node B. K1-K100 were requested by the operator of node A, while > >>>>K101-K1000 were requested by nodes connected to node A. Also, K1-K100 > >>>>are all related to documents describing plans to overthrow the evil > >>>>government of AAIR (it's a tropical country which depends mostly on > >>>>tourism). Node B is run by (you guessed it) the AAIR. At the same > >>>>time, the AAIR is running another node C, which mounts a timing attack > >>>>on node A to see whether it has keys K1-K1000. Under either solution > >>>>#1 or #2, node C would see that node A takes longer to find keys > >>>>K101-1000 than it does to find keys K1-K100. But since the AAIR know > >>>>that node A > >> > >>D'oh!!! I goofed: Node C would see that it takes node A LESS TIME to > >>find keys K101-K1000 than to find keys K1-K100, since A is trying to > >>hide the fact that it has K1-K100. > >> > >> > >>>>requested all of the keys, it also knows that the operator of node A > >>>>requested keys K1-K100 and is trying to hide that fact. > >>>> > >>>>Note that in the above scenario, K1-K100 don't have to be part of the > >>>>same splitfile. They just have to be of similar-enough subject matter > >>>>that the operator of node A would appear to have requested it IF > >>>>someone were to inspect his datastore. > >>> > >>> > >>>Hmm. I don't understand - why would they be accessed more quickly? Keys > >>>related in content are not related in the keyspace. > >> > >>Either you don't understand because I goofed (see above) or because you > >>didn't know the following: when I speak of K1-K1000, I'm naot talking > >>about keys 1 through 1000 in the keyspace. I'm talking about some > >>vector of keys in which I'm indexing each element by a number 1 through > >>1000. The keys are distributed in the keyspace in some more-or-less > >>uniformly random way. > >> > >>Does that clear things up? > > > > > >Not really. I assume you are working on the basis that we have fetched > >K1-K100, it has been in the store and been deleted by pcaching? > Not exactly. I'll try to be more clear: We have fetched K1-K100 as well > as K101-1000 all from node B. Nothing has been deleted by pcacheing. > The difference between K1-K100 and K101-K1000 is that: > > 1) the operator of node A intentionally requested K1-K100 while the rest > were requested by other nodes, > > 2) keys K1-K100 are all content-related (anti-AAIR government) in a way > that K101-K1000 are not. > > 3) Due to the proposed (bad) solutions #1 or #2, node A is now > pretending it doesn't have keys K1-K100, leading to higher search times. > The keys may have indeed been deleted, but due to the proposed > solution, not due to pcaching.
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. > > -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
