passkey leaking via DHT - an urban legend?

[Poke]

Many private trackers advice you to disable DHT, because otherwhise people could supposedly snoop your passkey, embedded in your announce url, and thereby impersonate you.

This oppinion is also vehemently held by several people I had recently discussions with, yet noone was able to offer any reliable source for this claim.

The whole thing sounds like an urban legend to me.

Everyone heard it from somebody else, and private trackers have a vested interest in disabling DHT, since that would interfere with their ratio enforcements.

My understanding of the DHT protokol is as follows:

http://www.bittorrent.org/beps/bep_0005.html

- The announce URL is not needed for it to work, since DHT is specifically made to work without the tracker. Sending it would be a complete waste of bandwith.

- there are only four message types in the DHT protocol as implemented in bittorrent: ping, find_node, get_peers, announce_peer. None of these contains anything like an announce url.

Therefore DHT should not be able to leak the announce url, including any embedded parameter. So the passkey is in no danger to be shared.

Can anyone here dispute this with some reliable proof and tell me where in the protokol it says otherwise?

Or better yet, can someone confirm this, so that I can point this thread out whenever this discussion comes up again?

Thanks for your help

[GTHK]

I can confirm that DHT doesn't transmit announce URL's, not in well behaved clients. Most clients are well behaved, the exceptions include an older version of BitComet which leaked DHT information for private trackers, and µTorrent 1.7.1, which was caused by a bug in it that was fixed promptly (hence the banning of only 1.7.1 on some trackers). Not only that, there's a flag called a private flag, added to torrents to mark them as private, disabling DHT for that torrent. Torrent makers, including µT's, allow you to set this flag. Anybody who believes otherwise without cause and can't be reasoned with don't know what they are talking about and don't know how to verify these very simple facts for themselves.

Anyone can poke around data sent by using a publicly available program called Wireshark, which captures data. And you can show DHT communications only by filtering by UDP + port.

[jewelisheaven]

At least in uT, for magnet support, ONLY the info dictionary is listed. The dictionary is sent over applicable peers with DHT enabled. Therefore for presumed private torrents in all respectful clients this is not a problem 1) because there is no tracker in the info dict, and 2) DHT is not enabled for private torrents. There is as you see a method to include trackers for magnet functionality however as there is no transfer of the base tracker which presumably has your sensitive announce key.... by default this idea of "leaks" are false and will be so. Thank you for your informed query and logic

EDIT: Frak! Nice reply GTHK

[Firon]

Passkey leaking was a rumored exploit on Azureus's DHT (and almost certainly fixed eons ago if it really existed).

BitComet did do it for some time, but it's a terribly broken client anyway.

[The8472]

generally speaking, things are only leaked when users/tracker admins don't set the private flag. If they don't it's their own fault.

[Poke]

Thanks for the informative responses. This will hopefully put the debate to rest.

What I do find curious is that there apparently was at a time some sort of truth to this DHT leakage for certain buggy versions. That would explain how this rumour started, but based on my simple analysis I do not really understand how it was possible.

I did not take into account the mentioned "magnet support", since I did not find that in the protocol, could you point out where this is described?

re: things are only leaked when users/tracker admins don't set the private flag.

For some reason there are trackers that do not enforce this flag consistently but insist on disabling DHT. Probably because it is easier for them.

[DreadWingKnight]

It takes maybe 5 lines of code in their .torrent uploader script to enforce the private flag. They have no valid reason.

[johny5]

So, the main conclusion of this discussion is that if DHT is in one or another way is disabled that there is no passkey leakage thru DHT.

How about situation, when DHT is enabled, torrent file is not private and so on, is there passkey information in DHT packets?

Thanks.

[DreadWingKnight]

How about situation, when DHT is enabled, torrent file is not private and so on, is there passkey information in DHT packets?

If there is, it's the torrent site's own fault.

[Firon]

No, there isn't passkey information in normal DHT packets, but because of the new magnet download function, you could end up sending someone the .torrent file (assuming it's not private).

But you know, the site is pretty incompetent if they don't have the private flag embedded.

[johny5]

Aha~ thank you for DHT. So, you've noticed magnet function.. As I remember, .torrent file contains my passkey embedded, probably maybe in hashed form. I just know, that if someone could get your .torrent file it can easily download the file under your account. And can 'hackers' extract my passkey from the .torrent file, or is there any other dangerous things around it?

And about embedding the private flag. The biggest russian torrent site, http://torrents.ru/, with 1.5 Million users sets their choice to allow DHT function enabled by default. Because this function helps to find peers faster and helps continuing downloading when server is down (it is down every morning for prophylaxis).

So, if it is not dangerous as it is said here, I can't see any reason why it would be wrong.

[Firon]

Anyone who managed to download the .torrent file from you through a magnet download would get your passkey, in this particular case.

[johny5]

Thanks

[Ultima]

Incorrect... >_>

Only the infodict (the most important part of a .torrent file) is sent for magnet URIs transfers -- nothing more. Peer discovery is then handled via DHT/PEX/LPD (or uh, manual adding of peers). The announce/announce-list keys are not sent with the infodict, so the passkey isn't sent via magnet URIs tranfers either.

This is exactly why µTorrent doesn't know the name of a torrent added/retrieved via magnet URIs (only the filenames).

Edit: Added the word "transfers" for clarity...

[thelittlefire]

Incorrect, uTorrent supports more than xt parameter in magnet URIs. Most people don't use them though (yet) http://bittorrent.org/beps/bep_0009.html

[Ultima]

metadata

This extension only transfers the info-dictionary part of the .torrent file. This part can be validated by the info-hash. In this document, that part of the .torrent file is referred to as the metadata.

So what's incorrect about the fundamentals of what I said? I may have been a bit inaccurate in my usage of terms (obviously, the metadata isn't sent as a part of the magnet URI itself), but I was clarifying what portion of the .torrent file metadata is sent (namely, not the announce/announce-list keys).

The tr variable is not an automatic thing that gets sent on a magnet request from other peers. It's just a part of the magnet URI itself that the client can use as another source for peers after it has received the metadata from the swarm. The fear that it was possibly sending the tracker URLs automatically was the reason behind this thread.

To clarify: magnet URIs are used only on entry, and has nothing to do with whether µTorrent itself sends a tracker during magnet transfers of header+metadata (it doesn't). It's up to whoever posts/generates the magnet URI itself to add the trackers, not the client sending the infodict metadata.

[Firon]

oic, I thought it transferred the entire torrent file.

[thelittlefire]

Completely correct sir

I'm sorry, usually I keep my mouth shut except for clarifications.. I'll try to be more accurate in my responses next time.