>
> Additionally, site insertors tend to use a fixed HTL; randomly not reducing
> the HTL provides substantial extra anonymity for them.
>
> > 50%         1 hop
> > 70%         1.9 hops
> > 80%         3.1 hops
> > 90%         6.6 hops
> > 95%         13.5 hops
> > 96%         17.0 hops
> > 97%         22.8 hops
> > 98%         34.3 hops
> > 99%         68.0 hops
> >

Let's say we choose a probability of 80% (3.1 hops average).  The node could 
then divide the number of desired hops by 3.1, and then send the request out. 
 The nodes on the path will choose to decrement 20% of the time.

This still gives probabilistic attacks.  If an attacker wants to determine 
wether a node downloaded a certain splitfile, each block can add to the 
attackers ability to determine wether the file exists on that node.  If a 
splitfile is broken up into 1000 blocks on a node with 80% probability of 
passing a 1 htl request.  Every (average) 3.1 blocks he requests, he gains a 
50% certainty that the file exists on that node (if they all return.  If one 
doesn't, then he knows it does not exist.  I won't even get into the 
complications FEC adds to these probabilities).  That means after 21.6 
(average) blocks, an attacker has 99% certainty that the file exists on a 
given node.  This does replicate the data, but there are other problems with 
a node knowing the data.

What I am proposing is to essentially make all HTLs 1 (therby removing the 
need for HTL), and setting the probability of continuing the request high so 
that there are enough hops, and so that it is very difficult for attackers to 
get information with decent certainty.  No intermediate nodes that the 
request routes to will get any information off the HTL either.  A malicous 
requeting node would not be able to do a 1-htl attack because it could not 
control the end of the request in any way.  Malicous intermediate nodes would 
be able to say their probability said to stop the request, but they could do 
that already by dropping the HTL down on reply, so no change there.  Any 
ideas on solving this problem?


Scott Young

_______________________________________________
freenet-tech mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/tech

Reply via email to