On Wed, Oct 15, 2003 at 06:34:34PM -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.
If that node had not enough bandwidth for its datastore, correct. However pcaching becomes a lot more useful when the store is full - we have to delete something, lets make it a (more) rational choice. > > 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. Yes. Statistical attacks on splitfiles can also be done by analysing requests sent from a node to another node in its RT - that attack can be mitigated by premix routing. 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? > > -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 -- 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
