On Thu, Oct 16, 2003 at 07:11:04AM -0700, Martin Stone Davis wrote: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:
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?
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.
-Martin
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
