I have a better attack. You are targetting a particular area of the keyspace. Request a long stream of random keys very close to the target key. They will all DNF, and reduce the pDNF in that area of each node the node routes the request to, until the estimator is so low that it tries a different node. Keep on requesting and you can effectively eliminate the node's ability to route requests in that region... I have no idea how to fight this attack :(. Anyone have any reason why it wouldn't work?
On Tue, Oct 28, 2003 at 11:20:47AM +0200, Jusa Saari wrote:
> On Mon, 27 Oct 2003 23:10:15 -0600, Tom Kaitchuck wrote:
>
> > If we had TUKs why would we ever have a request fail for data other
> > than: A. It really isn't in the network. or B. It used to be in the
> > network and fell out.
>
> C. People keep on using the old version of Frost ("the good old Frost").
>
> D. Someone purposefully sabotages the network by making an interesting-
> looking program that requests guessable keys.
>
> E. Someone makes such a program out of ignorance.
>
> F. Someone starts uploading something with FUQID, uses the "insert
> metadata first" -option, and posts the key. People start downloading,
> but of course most of the file parts aren't inserted yet.
>
> G. All of the above happen.
>
> The point is that this is a vulnerability in the network, and should be
> fixed.
>
> BTW. Would it be an effective attack, if someone would simply flood the
> network with queries for nonexisting keys ? It would at least disturb the
> malignant nodes neighbours...
>
> Would it be worth it to keep stats on the proportion of requests resulting
> in DNF of all requests from node A (that is, how many requests that have
> led to DNF we have gotten from A versus how many requests total we have
> gotten from A) and use that to decide how likely those DNF's a legitimate
> ? It should make such an attack more difficult, but would it have an
> adverse effect for routing ?
>
> Of course, if we have several bad apples, traversing the network
> (switching the attack targets, or simply changing their node key) it would
> defeat this defense... Hmm.
>
> > Frost can have each board on a SSK or 20 each with their own TUK. If the
> > TUK can be updated by any node that has the key, then all frost would
> > have to do is request the TUK. Then if that version was newer than what
> > you have you can request the new messages. There is no reason to try to
> > guess keys and request them. (The only thing I wonder about is if two
> > node insert the same new key at exactly the same time, and they cross
> > paths, what would happen?)
>
>
> Wouldn't this cause messages to be dropped (I insert a message at 10:00
> and someone else inserts his own at 10:01, therefore superceding my
> message) ? In any case, this would require work from both Frost developers
> and users part (but, if I understood it correctly, would solve the
> DBR/Edition freesite problems).
>
> _______________________________________________
> 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
