Ok, I had another crazy idea. This one is an idea to defeat the timing attacks we all know and hate. The attack goes like this: Request a file at HTL 0 from a node. The node has a 30% chance of forwarding the request to another node, if it doesn't have the file. The node returns the file quickly, and we conclude that the node must have the file in the store.
Solutions to this basically involve making it look like the node didn't have the file. One avenue of approach would be to try to emulate the slowness expected if we got the file from the next node on the chain. My suggestion: use the next node on the chain to emulate the latency of the next node on the chain! Send a special kind of request to the next node on the chain that requires it to route the request, return the datasource it would have routed to, and return the data we are sending to it. We would then send it back to the requestor in the usual way. An attacker who could surveil the network at an IP layer might be able to deduce we were sending it the data and it was returning us it through traffic analysis, but that is made harder by multiplexing, a reasonable traffic level, perhaps dividing the payload into several pieces and redirecting it through other nodes before it reaches the next node in the chain (in the hope of concealing it amidst regular traffic), or well known anti-traffic-analysis measures such as traffic padding. In any case it would be significantly better than we have now, at a moderate performance cost (it's only one extra hop in the base proposal). Thus the requesting node would not have a convincing case that we had the data in our store before they asked. Now, the question is, how important is our plausible deniability with respect to whether content was in our store before the request came in? Parts of freenet are designed to help this - for example the probabilistically not decrementing hops to live when HTL is low; but there are several ways to get around all these protections - requests at HTL 0 with timing information, announcements at HTL 0, and so on. If it is important, it may be possible to do something about it; if it is not, that may also make things easier. So, is it important? Now back to your regularly scheduled debugging. -- 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
