Rare yes, impossible no...  The main point of freenet is that nobody can
prove beyond a reasonable doubt ... anything ... about anyone ... using
freenet.

--b

On Wed, 10/15/03 at 18:34:34 -0700, Martin Stone Davis wrote:
> Pcaching only kicks in when the DS is 90% full, I thought.  So it 
> wouldn't apply to a node which kept a huge DS.
> 
> Also, isn't it the case that when inserting a large splitfile, the 
> various parts go through many different nodes? ...and so it would be 
> rare for you to have every part if you hadn't requested it.
> 
> -Martin
> 
> Brandon Low wrote:
> 
> >I believe that pcaching applies to local requests too... so why not just
> >let freenet take care of itself and stick to plausible deniability?  You
> >could just have been the first person in line for the insertion of said
> >key or whatever...
> >
> >--B
> >
> >On Wed, 10/15/03 at 18:14:21 -0700, Martin Stone Davis wrote:
> >
> >>AFAIK, it is possible right now to discover whether a node has requested 
> >>a particular large splitfile by measuring how much time it takes the 
> >>node to search for each part of the splitfile.
> >>
> >>To prevent such "timing attacks on the datastore", I thought at first 
> >>that a solution would be
> >>
> >>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.
> >>
> >>However, Iakin (I believe) pointed out that this is a bad idea because 
> >>we don't want freenet itself to break it's own anonymity: we don't want 
> >>someone to be able to inspect the operator's hard drive and say "ah ha! 
> >>you requested this key!".
> >>
> >>He suggested instead (if I understood correctly)
> >>
> >>SOLUTION #2: that keys that we request would somehow be moved into a 
> >>separate, encrypted store, and never placed in the main datastore.
> >>
> >>However, isn't there a problem with that as well?
> >>
> >>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 
> >>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.
> >>
> >>
> >>I'm having a lot of trouble coming up with a good solution.  Thoughts?
> >>
> >>-Martin
> >>
> >>
> >>_______________________________________________
> >>Devl mailing list
> >>[EMAIL PROTECTED]
> >>http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 
> _______________________________________________
> Devl mailing list
> [EMAIL PROTECTED]
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to