key=X field in tracker request string..Some questions..

[ReP0]

I tried searching but with the word "key" you get a million hits and it's almost impossible to find the one you are after so I hope someone can answer a simple questions.

Looking at the spec (see http://wiki.theory.org/BitTorrentSpecification) it says

"key: Optional. An additional identification that is not shared with any users. It is intended to allow a client to prove their identity should their IP address change."

Now my questions are

1) How does the key field provide a mechanism of proof of identity. It seems to change when the client is restarted each time so as far as I can see it's only for protection against "man in the middle" type attacks. That's fine and makes sense (well not really because if the man in the middle captured the packet he would of captured the key) but I just want to confirm that's about all it's good for and nothing more.

What confused me is the bit about "ip address change". Surely your up address will change most likely when you reboot your machine and given a restart of the client will generate a new "key" there is no way to link the old key to the new one to link the user to the ip change.

2) Using utorrent as my source of learning wrt behaviour of clients it looks like the "key" field is an 4 byte field consisting of hex chars and it seems to be randomly generated. Is it restricted to 4 bytes in length. Spec doesn't say anything about length of field.

3) Does any tracker use this field and if so in what way?

Not to be criticial but it almost seems like a totally useless field that in reality provides no security of verification really which is why I'm thinking that perhaps I'm misunderstanding this field and hope someone can fill me in.

Thanks for any input on the questions posed.

[DreadWingKnight]

1> During a session it does NOT change, even when an IP address changes. Some ISPs will cause an IP address change in the middle of a session (PPPoE and dialup ISPs specifically). Peer id + key is a better identifier than IP address + peer id. It prevents remote (hostile) users from being able to just harvest peer IDs on a tracker and send false announces indicating that the peer has stopped the torrent or other such nonsense.

2> Not always, Some keys are more than 4 bytes in length.

3> They have since the key parameter was introduced. They have used it as a security measure to prevent attacks. Mine included.

[ReP0]

"1> During a session it does NOT change, even when an IP address changes. Some ISPs will cause an IP address change in the middle of a session (PPPoE and dialup ISPs specifically). Peer id + key is a better identifier than IP address + peer id. It prevents remote (hostile) users from being able to just harvest peer IDs on a tracker and send false announces indicating that the peer has stopped the torrent or other such nonsense."

Really? I didn't realise IP's could change once assigned for a session since it would result in a loss of connection for most applications which use sockets and not the done thing. It would only be if the router on the other end rebooted accidentily but I can see it may happen though rare so I didn't think it would be worth the effort. In any event most sockets would fail and you would need to close the socket in which case you would think that the torrent client would see it as a new connection and issue a "started" event. At least I would in my implementation...Seems strange to me.

It would make some sense in a UDP based setup though now that I think about it some more.

"2> Not always, Some keys are more than 4 bytes in length."

Ok good so no defined length as long as reasonable I guess.

"3> They have since the key parameter was introduced. They have used it as a security measure to prevent attacks. Mine included."

Hmm not sure how it would stop attacks. I mean if he is already smart enough to steal the custom .torrent file with the user specific passkey then not sure that a randomly generated key is going to do anything. What is stopping an attacker from issuing a new "started" event with his own key since the key is generated at the client and not the server and going from that point on. How do you know which one is valid. You can't assume that because you didn't get a "stopped" event that you can ignore the newer start technically since it may have gotten lost. I guess you could but it wouldn't exactly be "right" or foolproof.

I mean if the person wanted to screw a particular user over they'd just wait for the torrent to get a little older so that seeding would have most likely finished and just issue their own start msg. Seems like it's not much of a security measure when all is said and done.

Could you give me a hint in what way it stops attacks?

[DreadWingKnight]

In any event most sockets would fail and you would need to close the socket in which case you would think that the torrent client would see it as a new connection and issue a "started" event. At least I would in my implementation...Seems strange to me.

Such an interruption would not break the torrent's session in all technicality, so your implementation would leave a lingering DoS attack against the old IP. Someone who doesn't change the key/peerid combo would not. Tracker connections are not persistent, so they would not be dropped in between like you think they would be. There's no real way to properly detect such a drop as an IP change on the client size.