Tom Kaitchuck wrote:
The problem with this is that it doesn't really work. For the sake of argument, lets say that the time it takes your node to return some data is T, and the time it would take it to get it from the next node is T + 100.

Right now if we return is less than T+100, they can tell it came from us.

If you add another 100 delay in there, then they can still tell it came from you, because if it came from another node, it would have delayed too. So if you return in less than T + 200 they know it came from you.

Yes, we need to sometimes make nodes return the data without delay. Otherwise delaying does not make much sense. The question is, when is it safe for a node to return the data immediately. This is the case, when the attacker might have caused us to cache the data in a previous request.

For that purpose the data source in the data reply message must be signed by
the data source node. When a node in the chain rerequests the data, it will
show the signature. That causes the data source node not to add any delay to
its data reply.

An unsigned data request message is handled differently. The data reply will
be delayed as long that it looks as if the data reply came from a node two hops
away (without any extra delay), if necessary.

When the attacker sends an unsigned data request and gets the data back in
the minimum time, it may still be the case that the next two nodes (the second
is often the returned data source) did not have the data at the time of the
attackers request, but they have dropped it before and only kept
the signed data sources.

The attacker can then make a signed request to the data source node. The
node will answer it without delay. But the attacker might have caused it
to cache the data in the previous request.

The attacker can still find out, that a data item once has been in your
data store, but not that it currently is (without possibly putting it there first).

--
 Thomas

_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to