A while ago mrogers and I put together a design for a hack to increase security against local attackers doing correlation attacks.
It went pretty much like this: Every local request has a tunnel ID. This will be the same for a large group of correlated requests. In particular it will be the same for all requests made for any particular splitfile, and it may be the same for all requests made by a given client (e.g. frost, fproxy). Having said that, we may use multiple tunnels for increased speed; tunnel allocation policy is something we need to think about. And we may want to avoid some tunnels, because they are exceptionally slow. When a node receives a request with a tunnel ID, it encrypts the tunnel ID by a private symmetric key kept by the node for the purpose, and then uses the resulting number to decide: - Whether to remove the tunnel ID, and just route the request. (Say 33% probability). - If not, which node to route it to. Nodes below a certain trust level probably shouldn't get tunneled requests. This provides a reasonable level of anonymity against a local traitor; he can say that there is a 33% chance of requests with a given tunnel having come from the directly connected node, which sounds bad, but the alternative is the present situation: He can say with certainty that requests came from the directly connected node, if he can do a correlation attack. This is probably not compatible with our current load limiting/balancing algorithm, but it should be possible to make it compatible with token passing. It should also be possible to implement it before 0.7.0 (unlike premix routing, which will take significant resources to get right). There are two major complications. One is tunnel selection policy. The other is integration with token passing: different tunnels will receive tokens at different times, so we may have to bend the priorities to fit with the available tunnels. What do you think? Something for the beta? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060805/e66385ec/attachment.pgp>
