A .torrent file and a Magnet link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- Eine .torrent-Datei ist eine „Metainfo“-Datei. Das Info-Dictionary enthält die Länge des Torrent-Fragments, den Dateinamen und die Dateilänge (oder eine Liste von Dateien) sowie in Version 1 eine verkettete Liste von 20-Byte-SHA-1-Hashes, einen pro Fragment. Der Info-Hash ist der 20-Byte-SHA-1-Hash des ben-kodierten Info-Werts, berechnet anhand der kodierten Form, genau wie sie in der .torrent-Datei erscheint. Tracker-URLs befinden sich außerhalb dieses Dictionarys und können daher geändert werden, ohne die Identität des Torrents zu verändern. BitTorrent v2 (BEP 52) ändert das Hashing: Es verwendet SHA-256 mit einem Merkle-Baum pro Datei und einem hierarchischen Dateibaum. Die dateispezifischen „Fragmentebenen“ befinden sich außerhalb des Info-Dictionarys, und die Implementierungen … muss Prüfen Sie sie anhand der Wurzelfelder der einzelnen Teile darin. bep 0003 +2
- Ein Magnet-Link enthält keine Metadaten, sondern nur diese Kennung. Das Format ist magnet:?xt=urn:btih: für v1 oder xt=urn:btmh: für v2, optional mit Anzeigenamen (dn), Tracker (tr) und Peer-Adresse (x.pe). Ein Hybrid-Torrent kann sowohl btih- als auch btmh-Themen in einem Link enthalten. Zunächst ruft der Client die Metadaten anderer Peers mithilfe der BEP-9-Erweiterung ab. Diese Erweiterung überträgt nur den Info-Wörterbuch-Teil der .torrent-Datei in 16-KiB-Blöcken. Der Client vergleicht diesen dann mit dem Hash im Link. Falls der Link keinen Tracker angibt, verwendet der Client den DHT, um Peers zu finden. bep 0009 +2
Beide Formate greifen also auf denselben Serverschwarm zu und liefern nach dem Start denselben Download. Sie unterscheiden sich lediglich in der Herkunft der Metadaten:
Eine .torrent-Datei ist ein statisches Artefakt: Die Dateiliste ist sofort bekannt, die Metadaten überstehen einen toten Schwarm, und die Datei muss irgendwo gehostet werden.
Ein Magnet-Link ist eine kurze Zeichenkette, die überall eingefügt werden kann, aber nur funktioniert, solange mindestens ein erreichbarer Peer die Metadaten noch besitzt. Keines der beiden Formate authentifiziert den Herausgeber oder bestätigt, dass der Inhalt mit seiner Bezeichnung übereinstimmt. Der Hash beweist lediglich, dass die Daten mit dem Hashwert übereinstimmen.
Tipp: Auf vielfachen Wunsch dient dieser Beitrag als Ergänzung zu all unseren Artikeln über Torrent und P2P für Ingenieure.
Geschichte und Hintergrund
Das .torrent-Format stammt aus dem ursprünglichen BitTorrent-Design. Bram Cohen entwarf das Protokoll im April 2001 und veröffentlichte die erste Version am 2. Juli 2001. Er und Ashwin Navin gründeten 2004 BitTorrent, Inc. (später Rainberry, Inc.). Cohen ist außerdem der eingetragene Autor von BEP 3, der Kernspezifikation, die die Metainfo-Datei und den Info-Hash definiert. Die Weiterentwicklung wird über den BitTorrent Enhancement Proposal-Prozess koordiniert, der den PEPs von Python nachempfunden ist. Cohen legte Wert darauf, dass der Hauptclient Open Source bleibt.
Die BEP-3-Spezifikation ist die formale Grundlage für die DateiformatDas v2-Format erschien deutlich später: BitTorrent, Inc. veröffentlichte die v2-Spezifikation am 15. Mai 2017. Magnet-Links haben eine andere Entstehungsgeschichte. Das Magnet-URI-Schema wurde nicht für BitTorrent entwickelt. Es war als projektneutrale Methode zur Identifizierung von Dateien anhand ihres Inhalts-Hashs in verschiedenen P2P-Netzwerken konzipiert. Die IANA führt es lediglich als vorläufiges Schema, das 2012 beim Magnet-URI-Projekt als dessen Urheber registriert wurde. Sekundärquellen datieren die Einführung auf 2002, jedoch konnte ich keine Primärquelle für dieses Datum finden. Die Verwendung von Magnet-Links durch BitTorrent basiert auf BEP 9, verfasst von Greg Hazel und Arvid Norberg (Norberg ist auch der ursprüngliche Autor von libtorrent). BEP 9 ist noch immer nur „Akzeptiert“, nicht endgültig, und erhielt 2016 den x.pe-Peer-Adressparameter. Dieses BEP definiert sowohl das Metadatenaustauschprotokoll als auch das BitTorrent-Magnetformat, aber in den Notizen eines Implementierers werden Magnet-URIs als De-facto-Konvention und nicht als nummeriertes BEP beschrieben.
In der Praxis basieren beide Formate auf dem BEP-Prozess und den Umsetzungen der Großkunden, nicht auf einem formalen Normen Körper.
1. Grundlagen
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Was es ist | Eine kleine Binärdatei (bencodiertes Wörterbuch) | Ein Text-URI (magnet:?xt=urn:btih:…) |
| Enthält den Inhalt? | Nein, nur Metadaten | Nein, nur eine Kennung. |
| Kerninhalte | Tracker-URL(s), Dateinamen und -größen, Länge der einzelnen Teile, Hashwert jedes Teils, optionaler Kommentar, Ersteller und Datum | Info-Hash (xt), optionaler Anzeigename (dn), Tracker (tr), Peer-Adressen (x.pe); Web-Seeds (ws) nur als clientabhängige Erweiterung, nicht in BEP 9 definiert. |
| Typische Größe | Einige KB bis mehrere MB (wächst mit der Inhaltsgröße) | Etwa 100-500 Bytes |
| Verwendeter Identifikator | SHA-1-Info-Hash (v1), SHA-256 (v2) oder beides (Hybrid) | Derselbe Info-Hash: Urne:btih (v1) oder urn:btmh (v2) |
| Spezifikation | BEP 3 (v1), BEP 52 (v2) | BEP 9 (Metadatenaustausch und Magnet-URI-Format) |
| Protokollhandler | Durch Dateizuordnung geöffnet (.torrent) | Vom Betriebssystem oder Browser geöffnet: URI-Handler |
2. Metadaten und Dateiinformationen
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Dateiliste vor Downloadbeginn sichtbar | Ja, sofort. | Nein, erst nachdem Metadaten von Peers abgerufen wurden. |
| Metadatenquelle | Im Dateisystem eingebettet | Von anderen Servern (DHT, PEX, Tracker) über ut_metadata heruntergeladen |
| Metadatenintegrität | Durch Hashing verifiziert | Die Metadaten wurden anhand des Info-Hashs im Link verifiziert, daher werden manipulierte Metadaten abgelehnt. |
| Startverzögerung | Keiner | Sekunden bis Minuten (oder nie, falls kein Peer die Metadaten besitzt) |
| Anzeigename | Gespeichert in der Datei (Name) | dn ist optional und nicht verifiziert; es ist lediglich ein Label. |
| Stück-Hashes | Inklusive | Später mit den Metadaten erhalten |
| Bearbeitbar | Tracker können bearbeitet werden, ohne den Hash zu ändern. Durch Bearbeiten des Info-Wörterbuchs wird der Info-Hash geändert, wodurch ein anderer Torrent entsteht. | Die Bearbeitung als Text ist unkompliziert (Tracker hinzufügen oder entfernen). Der Info-Hash kann nur geändert werden, indem auf andere Inhalte verwiesen wird. |
3. Autor, Herkunft und Authentizität
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Informationen zum Autor | Optionale Felder: Erstellt von (Kunde und Version), Erstellungsdatum, Kommentar | Keines; es gibt kein Standard-Autorenfeld. |
| Metadatenleck über den Ersteller | Möglich (Clientversion, Zeitstempel, manchmal Kommentare oder URLs) | Minimal; der Link enthält nur das, was der Absender hinzugefügt hat. |
| Digitale Signatur | Es gibt zwar eine Erweiterung für die Signatur (BEP 35), diese wird jedoch selten genutzt. | Keiner |
| Prüfen Sie, ob der Inhalt dem entspricht, was auf dem Etikett steht. | Keine, und der Name kann gefälscht sein. | Keine, und dn kann gefälscht sein. |
| Prüfen Sie, ob der Inhalt mit dem Hash übereinstimmt. | Ja, jedes einzelne Stück ist hash-verifiziert. | Ja, jedes einzelne Element wird nach der Metadatenverarbeitung einer Hash-Verifizierung unterzogen. Überprüfung |
| Vertrauensmodell | Sie vertrauen demjenigen, der die Datei geliefert hat, und überprüfen dann die Daten anhand der Hashwerte. | Sie vertrauen der Person, die den Link bereitgestellt hat, und überprüfen ihn dann auf die gleiche Weise. |
| Spoofing-Risiko | Gefälschte Torrents mit demselben Titel sind weit verbreitet. | Dasselbe gilt, und der Link bietet noch weniger Kontext (keine Dateiliste, die man zuerst überprüfen könnte). |
4. Hosting, Vertrieb und Verfügbarkeit
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Hosting erforderlich | Ja, ein Webserver, eine Indexseite oder eine Dateifreigabe. | Nein, es ist nur Text und kann überall eingefügt werden. |
| Sharing-Methoden | Herunterladen, E-Mail-Anhang, Dateiübertragung (Anhänge werden manchmal blockiert) | Chat, E-Mail-Text, QR-Code, Forenbeitrag, Notizen-App |
| Enthüllung | Gehostete Dateien können entfernt oder blockiert werden. | Schwerer zu entfernen (reiner Text), aber die Seiten, die ihn veröffentlichen, können weiterhin blockiert werden. |
| Link rot | Die Datei bleibt so lange erhalten, wie der Host existiert. | Der Text ist zwar erhalten, aber nutzlos, wenn kein anderer Nutzer mehr über die Metadaten verfügt. |
| Archivierungswert | Hoch: Es bewahrt die vollständigen Metadaten auch dann, wenn der Schwarm tot ist. | Niedrig: Es ist auf einen aktiven Schwarm angewiesen, um Metadaten abzurufen. |
| Index- und Suchseiten | Für jeden Torrent muss eine Datei gespeichert werden (mehr Speicherplatz). | Bewahren Sie nur eine kurze Schnur auf (billiger und einfacher zu spiegeln) |
| Geräteübergreifender Komfort | Dateiübertragung erforderlich | Ganz einfach: kopieren und einfügen oder einen QR-Code scannen |
| Browserverhalten | Lädt eine Datei herunter und öffnet sie anschließend in einem Client. | Löst eine Protokollbehandlungsaufforderung aus (erfordert einen registrierten Client) |
5. Netzwerkverhalten und -leistung
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Peer-Entdeckung | Die in der Datei aufgeführten Tracker sowie DHT, PEX und LSD (sofern nicht privat). | DHT, PEX und LSD sowie alle TR-Tracker im Link |
| Funktioniert ohne Tracker. | Nur wenn die DHT-Messung zulässig ist | Ja, mit DHT (das ist der übliche Modus). |
| Abhängigkeit von DHT | Optional | Oft unerlässlich für Metadaten und Peers |
| Web-Seeds (HTTP-Quellen) | URL-Liste / httpseeds-Felder (BEP 19) | ws= Parameter, eine clientabhängige Erweiterung, die in BEP 9 nicht definiert ist. |
| Downloadgeschwindigkeit nach dem Start | Identisch | |
| Verhalten bei toten oder seltenen Torrents | Startet und wartet auf Gleichaltrige | Kann bei „Abrufen von Metadaten“ hängen bleiben. |
| Private Tracker | Vollständig unterstützt (privates Flag, Passkey in der Ankündigungs-URL) | Im Allgemeinen unbrauchbar. Private Torrents deaktivieren DHT/PEX, und der Tracker-Passkey wird nicht in einem teilbaren Link offengelegt. |
6. Sicherheit
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Quelle des Malware-Risikos | Der heruntergeladene Inhalt, nicht das Format | Der heruntergeladene Inhalt, nicht das Format |
| Parser- oder Handler-Risiko | Fehlerhafter Bencode kann in einem schlecht programmierten Client zu Fehlern führen (selten). | Bösartige DN- oder URI-Parameter können zu Injection- oder Anzeigefehlern in schlecht programmierten Clients oder Handlern führen (selten). |
| Möglichkeit zur Überprüfung vor dem Herunterladen | Hoch: Sie sehen zuerst die Dateiliste, die Dateierweiterungen und die Dateigrößen. | Niedrige Priorität, bis die Metadaten eintreffen; die meisten Clients ermöglichen es Ihnen dann, die Dateiliste vor dem Herunterladen zu überprüfen. |
| Getarnte ausführbare Dateien | In der Dateiliste erkennbar (.exe, .scr, .lnk usw.) | Dasselbe gilt, aber erst nachdem die Metadaten abgerufen wurden. |
| Phishing- und Werberisiken | Torrent-Seiten sind oft mit Werbung überladen. | Dasselbe gilt zusätzlich für versehentliche Klicks auf ähnlich aussehende Magnetknöpfe. |
| Hashstärke | SHA-1 für v1 (theoretisch kollisionsschwach, schwer für Torrents auszunutzen); SHA-256 für v2 | Derselbe Hash wie der Torrent, auf den es verweist. |
| Manipulation während des Transports | Erkannt durch Stückhashes | Erkannt über den Info-Hash, obwohl ein vertauschter Link auf völlig andere Inhalte verweist. |
7. Datenschutz und Anonymität
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Ihre IP-Adresse ist für andere Nutzer sichtbar | Ja | |
| Ihre IP-Adresse ist für Tracker sichtbar | Ja (eingebettete Tracker) | Ja, wenn TR-Tracker enthalten sind. |
| DHT-Exposition | Möglich | Mit an Sicherheit grenzender Wahrscheinlichkeit; Ihre Anfragen werden an das öffentliche DHT gesendet. |
| Anonymitätsunterschied | Keine aussagekräftigen | |
| Metadaten, die den Teiler preisgeben | Erstellt von, Kommentar und Erstellungsdatum können Details preisgeben | Nichts, was über den Inhalt des Links hinausgeht |
| Minderungsmaßnahmen | VPN oder Proxy, clientseitig Verschlüsselungprivate Tracker | |
8. Risiken und Einschränkungen
| Risiko | .torrent-Datei | Magnetlink |
|---|---|---|
| Stände ohnegleichen | Wartet auf Gleichaltrige | Möglicherweise werden die Metadaten nie erfasst. |
| Gefälschte oder falsch gekennzeichnete Inhalte | Möglich | |
| Rechtliche Risiken | Das hängt vom Inhalt und der jeweiligen Rechtslage ab. Das Hosten der Datei kann den Website-Betreibern mehr Sichtbarkeit verschaffen. | Das hängt vom Inhalt und der jeweiligen Rechtslage ab. Das Teilen von Links wird mitunter anders behandelt als das Hosten von Dateien, aber das ist nicht immer eindeutig und bietet keine absolute Sicherheit. |
| Datenschutzverletzung | Tracker- und Peer-Sichtbarkeit | DHT und Peer-Sichtbarkeit |
| Tod eines Trackers | Verringert die Entdeckungsmöglichkeiten, aber das DHT könnte trotzdem funktionieren. | Kein Problem, wenn die Verbindung auf DHT basiert. |
| Langzeitbeständigkeit | Besser | Schlechter |
| Tippfehler und Kürzungen | Eine beschädigte Datei wurde erkannt | Ein Tippfehler im Hashwert führt zu keinem Ergebnis, und ein abgeschnittener Link wird stillschweigend deaktiviert. |
9. Kompatibilität und Benutzerfreundlichkeit
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Kundensupport | Universal | Universell einsetzbar bei modernen Kunden (erfordert BEP 9) |
| Seedboxen und Webdienste | Universell unterstützt | Weitgehend unterstützt, obwohl einige ältere Dienste nur Dateien akzeptieren. |
| Mobilfreundlichkeit | Mittel (die Handhabung heruntergeladener Dateien ist umständlich) | Hoch |
| Automatisierung (RSS, Skripte, APIs) | Einfach | Außerdem ist es unkompliziert und leichter zu verstauen. |
| Menschliche Lesbarkeit | Ohne Hilfsmittel nicht lesbar. | Der Hashwert ist undurchsichtig, aber die Struktur ist lesbar. |
10. So erstellen Sie .torrent-Dateien und Magnet-Links
Bei den mit einem Dolch gekennzeichneten Punkten handelt es sich um meine eigene Schlussfolgerung oder mein allgemeines Wissen, die nicht durch eine Quelle bestätigt sind.
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Starteingabe | Ihre eigentlichen Dateien oder Ihr Ordner, plus ein Erstellungstool (zum Beispiel mktorrent oder die Funktion „Torrent erstellen“ eines Clients) | Ein vorhandener Info-Hash. In Version 1 ist das der SHA-1-Hash des bencoded-Info-Wörterbuchs, daher kann kein Magnet-Link existieren, bevor die .torrent-Metadaten vorhanden sind. |
| Reihenfolge der Schritte | 1) Stücklänge wählen. 2) Jedes Stück hashen. 3) Informationswörterbuch erstellen. 4) Äußere Felder wie Tracker hinzufügen. 5) Bencodieren und speichern. | 1) Torrent herunterladen. 2) Info-Hash ermitteln. 3) URI mit xt schreiben. 4) Optional dn, tr und x.pe hinzufügen. |
| Stücklänge | Sie wählen den Wert. Er ist fast immer eine Zweierpotenz, am häufigsten 256 KiB. mktorrent verwendet standardmäßig 2^18 Bytes und legt ihn mit der Option -l fest. | Keine; es wurde vom Strom geerbt. |
| Hashing-Arbeit | Jedes Byte wird gehasht: SHA-1-Fragmente für v1, SHA-256-Merkle-Bäume pro Datei für v2. Die Laufzeit steigt mit der Datengröße (dagger), und mktorrent kann mehrere Threads verwenden. | Vernachlässigbar: nichts über den bestehenden Hash hinaus. |
| Tracker | announce oder announce-list. Die Liste befindet sich außerhalb des Infobereichs; falls vorhanden, ignorieren kompatible Clients announce, und die Ebenen werden der Reihe nach durchprobiert, wobei die URLs innerhalb einer Ebene zufällig angeordnet werden. | tr-Parameter in der URI. Falls keine angegeben sind, sollten Clients das DHT verwenden. |
| Privatflagge | Die Einstellung wird durch Setzen von `private=1` im Info-Dictionary vorgenommen. Konforme Clients melden sich dann nur noch beim privaten Tracker an und verbinden sich nur mit den von diesem zurückgegebenen Peers. Da es sich um interne Informationen handelt, beeinflusst dies den Info-Hash (Dagger). | Im Link ist kein Feld dafür vorhanden. Das Flag befindet sich in den Metadaten, die der Client erst nach dem Abruf sieht (dagger). |
| Web-Samen | Die URL-Liste wird gemäß BEP 19 von mktorrent als -w bereitgestellt. Der HTTP/FTP-Server fungiert als permanent ungedrosselter Seed. | ws= ist nicht Teil der Parameterliste von BEP 9. Behandeln Sie es als clientabhängige Erweiterung. |
| Optionale beschreibende Felder | Kommentar und Erstellungsdatum sind optional. mktorrent bietet die Option -c für einen Kommentar und -d zum Weglassen des Datums. | Nur der Anzeigename (dn). Es handelt sich um eine Bezeichnung, die nicht verifiziert ist. |
| Source tag | mktorrent's -s bettet eine Quellzeichenkette in den Info-Hash ein, sodass dieselben Dateien mit einem anderen Tag einen anderen Hash und einen separaten Swarm erhalten. | Nicht zutreffend |
| Was verändert die Identität? | Alle internen Informationen: Name, Stücklänge, privates Flag, Quell-Tag, Dateiliste (Dagger) | Die Änderung von xt verweist auf einen anderen Torrent. Die Änderung von dn, tr oder x.pe hat keine Auswirkung. |
| Hash-Versionsauswahl | v1 (SHA-1), v2 (SHA-256) oder Hybrid, bei der Erstellung ausgewählt. | Der Link muss btih, btmh oder beides für einen Hybrid-Torrent enthalten (BEP 9 erlaubt beide Themen in einem Magnet-Link, wenn sie denselben Hybrid-Torrent beschreiben). |
| Unterzeichnung | BEP 35 erlaubt in die Datei eingebettete RSA-Signaturen, optional mit einem X.509-Zertifikat, und mehrere Signaturen pro Torrent. Es wird selten verwendet (dagger). | BEP 9 definiert kein Signaturfeld, daher gibt es nichts zu unterschreiben. |
| Ausgabe | Eine Binärdatei mit der Umrechnung von KB in MB, die Sie hosten oder senden müssen. | Eine Textzeile von einigen hundert Bytes |
| Dadurch wird es nutzbar gemacht | Laden Sie die Datei hoch und starten Sie einen Client mit den Originaldaten, um die Daten zu initialisieren. | Veröffentliche die Zeile und fahre mit dem Seeding fort. Der Link ist nutzlos, wenn kein Peer die Daten und Metadaten besitzt. |
| Typische Fehler | Falsche Stückgröße für die Inhaltsgröße (†); Vergessen des privaten Flags vor der Veröffentlichung, da eine spätere Änderung einen neuen Hash erfordert (†); Hinzufügen des falschen Trackers | Tippfehler oder abgeschnittener Hash, daher verweist der Link stillschweigend ins Leere (†); falsches Präfix (btih vs. btmh); nicht maskierte Sonderzeichen in dn (†) |
11. Jedes einzelne verwenden
Bei den mit einem Dolch gekennzeichneten Punkten handelt es sich um meine eigene Schlussfolgerung oder mein allgemeines Wissen, die nicht durch eine Quelle bestätigt sind.
| Aspekt | .torrent-Datei | Magnetlink |
|---|---|---|
| Wie man es öffnet | Doppelklicken Sie über die Dateizuordnung, ziehen Sie die Datei in einen Client oder verwenden Sie „Torrent-Datei hinzufügen“. | Klicken Sie auf einen Magneten: Link (erfordert einen registrierten Handler), fügen Sie ihn in einen Client ein oder scannen Sie einen QR-Code (Dolch). |
| Was der Kunde zuerst tut | Analysiert die bencodierten Metainformationen | Analysiert die URI und extrahiert den Info-Hash. |
| Woher Metadaten stammen | Bereits in der Datei vorhanden | Die Peers senden das Informationswörterbuch (nur diesen Teil der .torrent-Datei) in 16-KiB-Blöcken über die BEP-9-Erweiterung, und der Client überprüft es anhand des Hashwerts. |
| Gleichgesinnte finden | Tracker aus der Datei sowie DHT/PEX/LSD, es sei denn, der Torrent ist privat. Bei privaten Torrents dürfen DHT und PEX nicht verwendet werden. | Tracker im Link; falls keine vorhanden, der DHT. |
| Startverzögerung | Keiner | Wartet, bis ein Peer mit den Metadaten antwortet, daher kann es unbegrenzt lange dauern. |
| Dateien vor dem Herunterladen auswählen | Sofort | Nachdem die Metadaten eingetroffen sind. Einige Clients können nur die Metadaten abrufen, um die Dateiliste vor dem Herunterladen anzuzeigen. |
| Vor der Bestätigung prüfen | Vollständige Prüfung mit einem beliebigen Parser-Tool, offline | Nicht möglich, bis die Metadaten abgerufen wurden. |
| Umrechnung zwischen ihnen | Berechne den Info-Hash und schreibe einen Magnet-Link (Dolch). | Die abgerufenen Metadaten können als Torrent exportiert und zwischengespeichert werden, sodass für denselben Magnet-Link nie ein zweiter Metadaten-Download erforderlich ist. |
| private Tracker-Nutzung | Funktioniert, da die Datei die Tracker-URL enthält und Clients sich darauf beschränken müssen (BEP 27). | Vermutlich unpraktisch: Der Link ist nicht gekennzeichnet, und eine Tracker-URL kann persönliche Daten enthalten (†). BEP 27 behandelt keine Magnetlinks. |
| Bearbeitung | Tracker können hinzugefügt oder entfernt werden, ohne den Hash zu ändern, da sie sich außerhalb des Infobereichs befinden. Durch Bearbeiten der Info wird ein neuer Torrent erstellt. | Bearbeiten Sie den Text nach Belieben; durch Ändern von xt ändert sich, um welchen Torrent es sich handelt. |
| Echtheitsprüfung | Überprüfen Sie eine BEP-35-Signatur anhand eines vertrauenswürdigen Zertifikats. Eine Bibliothek weist darauf hin, dass ihre Prüfung das Zertifikat selbst nicht validiert. Andernfalls überprüfen Sie die Dateiliste. | Vergleichen Sie den Info-Hash mit einem Wert aus einer vertrauenswürdigen Quelle; es ist nichts anderes verfügbar. |
| Automatische Updates | BEP 39 erlaubt es einem Ersteller, eine Update-URL im Info-Dictionary zu hinterlegen, und Clients laden neuere Torrents nur dann automatisch herunter, wenn diese vom Ersteller signiert wurden. | Keiner |
| Weiterverbreiten | Senden oder hosten Sie die Datei | Kopieren Sie die Zeile und fügen Sie sie ein. |
| Wenn es fehlschlägt | Tracker ausgefallen oder keine Peers: Der Client wartet. Eine beschädigte Datei wird abgelehnt. | Tippfehler im Hash oder kein erreichbarer Peer: hängt bei „Abrufen von Metadaten“ fest. |
| Web-Samenrettung | Ein .torrent mit Web-Seed funktioniert auch ohne Peers. Magnet-Links haben kein Äquivalent, da weder BEP 9 noch die HTTP-Seeding-BEPs eine Möglichkeit bieten, Metadaten von den HTTP-Seeds abzurufen. | |
| Nach dem Herunterladen | Verwenden Sie weiterhin dieselben Dateien zum Seeden. | |
Zusammenfassung
Torrent-Dateien (.torrent) eignen sich am besten für die Archivierung, private Tracker, die vorherige Überprüfung der Dateiliste und Offline-Metadaten, während Magnet-Links sich durch schnelles Teilen, QR-Codes, Tracker-unabhängige Verteilung und minimalen Hostingaufwand auszeichnen.
Keines der beiden Formate ist an sich sicherer. Beide überprüfen die Datenintegrität kryptografisch, aber keines authentifiziert den Herausgeber oder den Inhalt selbst. Das eigentliche Sicherheits- und Rechtsrisiko liegt im Inhalt und der Quelle. Prüfen Sie daher die Dateiliste auf verdächtige Dateiendungen und achten Sie genau darauf, woher Sie den Link haben.
Häufig gestellte Fragen
Ist BitTorrent ein IETF- oder ISO-Standard, und wie formal ist der Status von .torrent-Dateien und Magnet-Links?
Nein. Das Protokoll wird durch BitTorrent Enhancement Proposals (BEPs) spezifiziert, einem Prozess, der den PEPs von Python nachempfunden ist. BEP 3 definiert das Metainfo-Format und BEP 52 die Version 2. BEP 9, das den Metadatenaustausch und das BitTorrent-Magnet-Format abdeckt, hat den Status „Akzeptiert“, nicht „Final“. Das Magnet-URI-Schema selbst ist lediglich eine vorläufige IANA-Registrierung, die vom Magnet-URI-Projekt entwickelt wurde. In der Praxis wird die Interoperabilität durch die gängigen Client-Bibliotheken definiert; daher sollten Sie verschiedene Implementierungen testen.
Verknüpft der Info-Hash einen Torrent kryptografisch mit seinem Inhalt?
Transitiv gesehen ja. Der v1-Info-Hash ist der SHA-1-Hash des bencoded-Info-Wörterbuchs, und dieses Wörterbuch enthält den SHA-1-Hash jedes einzelnen Datenelements. Der Hash ist also fest in den Daten verankert. Der Haken an der Sache ist die schwächere Kollisionsresistenz von SHA-1: In der Praxis treten Kollisionen auf, sodass ein Herausgeber, der beide Varianten eines Torrents erstellt, zwei Payloads mit demselben Hash erzeugen könnte. Second-Preimage-Angriffe auf einen bestehenden Torrent sind weiterhin nicht möglich. v2 verwendet SHA-256 und behebt dieses Problem.
Welche Bearbeitungen verändern die Identität eines Torrents und welche nicht?
Alles innerhalb des Info-Dictionaries ändert den Info-Hash: Name, Dateiliste, Stücklänge, das private Flag und ein Quell-Tag wie die Option `-s` von mktorrent. Felder außerhalb des Info-Dictionaries, wie `announce` und `announce-list` (BEP 12), können frei bearbeitet werden, ohne einen neuen Torrent zu erstellen. Bei einem Magnet-Link beeinflussen `dn`, `tr` und `x.pe` niemals die Identität; nur `xt` hat Einfluss. Änderungen am Info-Dictionary führen im Hintergrund zu einer Abspaltung des Torrent-Swarms; behandeln Sie dies daher wie die Veröffentlichung eines neuen Torrents.
Wie authentifiziert ein Client Metadaten, die über einen Magnet-Link empfangen werden?
Peers senden das Informationswörterbuch in 16-KiB-Blöcken über die BEP-9-Erweiterung ut_metadata. Der Client berechnet den Hash des zusammengesetzten Ergebnisses und vergleicht ihn mit dem Info-Hash des Links. Gefälschte Metadaten werden zurückgewiesen, es sei denn, der Angreifer kann den Hash knacken. Dies beweist die Integrität relativ zum Link, nicht die Richtigkeit. Der DN-Wert ist eine unbestätigte Bezeichnung, und der Hash gibt keine Auskunft darüber, wer den Inhalt veröffentlicht hat oder was er tatsächlich enthält.
Was sind die praktischen Unterschiede zwischen v1-, v2- und Hybrid-Torrents?
Version 1 verwendet eine flache Liste von SHA-1-Piece-Hashes im Info-Dictionary. Version 2 (BEP 52) verwendet SHA-256 mit einem Merkle-Baum pro Datei und einem hierarchischen Dateibaum. Die Piece-Layer befinden sich außerhalb des Info-Dictionaries und müssen von Implementierungen mit den entsprechenden Root-Feldern der Pieces verglichen werden. Ein Hybrid-Torrent enthält beide Strukturen und somit zwei Info-Hashes. Ein Magnet-Link kann sowohl btih- als auch btmh-Topics enthalten. Stellen Sie sicher, dass Ihr Client und Ihre Tools Version 2 unterstützen, bevor Sie ausschließlich Version-2-Torrents veröffentlichen.
Kann ein Magnet-Link einen Download starten, wenn keine Peers vorhanden sind, aber ein HTTP-Web-Seed existiert?
Nein. BEP 9 ruft Metadaten nur von Peers ab, und weder BEP 9 noch die HTTP-Seeding-BEPs (17, 19) definieren eine Methode zum Abrufen von Metadaten von einem HTTP-Seed. Eine .torrent-Datei mit einem Web-Seed funktioniert auch mit null Peers, da die Metadaten bereits in der Datei enthalten sind. Wenn Sie auf Web-Seeds für die Verfügbarkeit angewiesen sind, verteilen Sie die .torrent-Datei und nicht nur einen Magnet-Link.
Was gibt jedes Format über meine Privatsphäre und meine Netzwerkidentität preis?
Beide Methoden legen Ihre IP-Adresse für andere Nutzer und Tracker offen, die Sie ankündigen. Magnet-Links basieren typischerweise auf dem öffentlichen DHT, wodurch ein weiterer Suchpfad entsteht, über den Ihre IP-Adresse und der Info-Hash sichtbar werden. Protokollverschlüsselung verschleiert den Datenverkehr, anonymisiert Sie aber nicht. Private Torrents (BEP 27) verlangen von Clients die ausschließliche Nutzung des privaten Trackers, sodass DHT und PEX nicht verwendet werden. Für Anonymitätsanforderungen sollten Sie ein Bedrohungsmodell mit geeigneten Maßnahmen zur Netzwerkabwehr verwenden, nicht die Wahl des Formats.
Wie kann ich die Authentizität und nicht nur die Integrität von Daten überprüfen, die ich über Torrent erhalten habe?
Die Überprüfung einzelner Datenteile bestätigt lediglich, dass die Daten mit dem Torrent übereinstimmen. Um die Authentizität sicherzustellen, sollte man eine Prüfsumme oder Signatur (z. B. ein signiertes SHA-256-Manifest) über einen unabhängigen, vertrauenswürdigen Kanal einholen und die fertigen Dateien damit vergleichen. BEP 35 definiert in .torrent-Dateien eingebettete RSA-Signaturen mit optionalen X.509-Zertifikaten und mehreren Unterzeichnern. Diese Norm wird jedoch selten eingesetzt, und eine Bibliothek, die sie implementiert, weist darauf hin, dass ihre Überprüfung das Zertifikat selbst nicht validiert. Magnet-Links verfügen über keinen Signaturmechanismus.
Wie wähle ich die Stücklänge beim Erstellen eines Torrents?
Es handelt sich um einen Kompromiss zwischen Metadatengröße und Übertragungsgranularität. BEP 3 besagt, dass die Stücklängen fast immer Zweierpotenzen sind, üblicherweise 256 KiB, was auch der Standardwert von mktorrent ist. In Version 1 besteht eine 100-GiB-Nutzlast mit 256 KiB aus 409.600 Teilen, sodass allein die Teilezeichenkette etwa 8 MB groß ist. Magnet-Clients müssen dieses gesamte Wörterbuch in etwa 500 Blöcken laden, bevor sie starten können. Daher verlangsamen übergroße Metadaten den Start von Magnet-Links. Größere Teile reduzieren zwar die Metadaten, erschweren aber die Reparatur nach einem Fehler in einem Teil.
Warum landen zwei Ströme identischer Daten in getrennten Datenschwärmen, und wie kann ich das vermeiden?
Da der Info-Hash das gesamte Informationswörterbuch umfasst, führen unterschiedliche Namen, Dateireihenfolgen, Segmentlängen, private Flags oder Quell-Tags selbst bei byteidentischen Nutzdaten zu unterschiedlichen Hashes. Um einen einheitlichen Schwarm zu gewährleisten, sollten Sie Segmentlänge, Namen, Dateireihenfolge und Flags in Ihrem Release-Prozess standardisieren und den Info-Hash zusammen mit dem Artefakt veröffentlichen. Quell-Tags dienen der bewussten Trennung von Schwärmen, und die Option `-s` von mktorrent ändert den Hash gezielt.
Welche Hauptsicherheitsbedenken bestehen beim Schreiben eines Clients oder Parsers für diese Formate?
Alle Eingaben sind als nicht vertrauenswürdig zu behandeln. Ben-Codierung ist streng zu validieren, die Metadatengröße ist zu begrenzen (ein Open-Source-Client erzwingt ein Limit von 32 MB) und Dateipfade in den Metadaten sind zu bereinigen, um Directory Traversal zu verhindern. Private und Loopback-Adressen, die von Trackern und dem DHT zurückgegeben werden, sind zu filtern, um SSRF-Missbrauch einzuschränken. Tracker-URLs sind vor dem Verbindungsaufbau auf ihre Gültigkeit zu prüfen. DN ist als nicht vertrauenswürdiger Text zu behandeln und jeder Hashwert ist vor dem endgültigen Speichern zu überprüfen.
Wie berechne ich den Info-Hash einer .torrent-Datei korrekt?
Ermitteln Sie den exakten Bytebereich des Info-Werts in der Datei und berechnen Sie den Hashwert dieser Bytes: SHA-1 für v1 oder SHA-256 für v2. BEP 3 betont, dass der Hashwert über die in der Datei vorhandene Kodierung berechnet werden muss. Das Dekodieren und erneute Kodieren des Wörterbuchs ist nur dann sicher, wenn der Dekodierer die Eingabe vollständig validiert hat. Ein toleranter Dekodierer kann Daten stillschweigend normalisieren und einen anderen Hashwert erzeugen. Bei hybriden Torrents berechnen Sie beide Hashwerte aus demselben Bytebereich.
Kann ich einen Magnet-Link für einen privaten Tracker-Torrent verwenden?
In der Praxis ist das oft nicht möglich. BEP 27 schreibt vor, dass Clients sich nur beim privaten Tracker anmelden und sich nur mit den von diesem zurückgegebenen Peers verbinden dürfen. Ein einfacher Magnet-Link enthält kein privates Flag, da dieses in den Metadaten gespeichert ist, und darf keine nutzbare Tracker-URL enthalten. Ist eine Tracker-URL mit Zugangsdaten eingebettet, behandeln Sie den Link als geheim. Dies ist meine Schlussfolgerung aus der Spezifikation, da BEP 27 Magnet-Links nicht direkt behandelt. Testen Sie dies daher mit den Regeln Ihres Trackers.
Sollte ich für die Verteilung von Software, Datensätzen oder Archiven in einer Pipeline einen .torrent- oder einen Magnet-Link veröffentlichen?
Veröffentlichen Sie beides, wobei die .torrent-Datei als kanonisches Artefakt dient. Dadurch bleiben die vollständigen Metadaten erhalten, Nutzer können die Dateiliste offline einsehen, und die Verfügbarkeit wird durch Web-Seeds (BEP 19) sichergestellt. Der Magnet-Link kann aus demselben Info-Hash abgeleitet werden. Veröffentlichen Sie den Info-Hash zusammen mit einer signierten Prüfsumme auf einem vertrauenswürdigen Kanal. Dies gewährleistet dauerhafte Archivierung und einfaches Teilen, ohne dass der Abruf von Metadaten von Peers abhängt.
Wovon hängt ab, wie lange ein Torrent abrufbar bleibt, und wie kann ich das verbessern?
Für die Auffindbarkeit der Daten ist mindestens ein erreichbarer Peer erforderlich, der die Daten enthält, und bei Magnet-Links zusätzlich einer, der die Metadaten enthält. Dies lässt sich verbessern, indem man die Seeder aktiv hält, mehrere Tracker in gestaffelten Ebenen (BEP 12) als Backup hinzufügt, HTTP-Web-Seeds einsetzt und die .torrent-Datei archiviert oder von Clients exportieren lässt, die abgerufene Metadaten zwischenspeichern. Ein Magnet-Link allein sichert keine Daten, daher ist er bei einem inaktiven Schwarm nutzlos.
Erweiterte Liste weiterführender Lektüre und Themen
- Bencoding: Das von .torrent-Dateien verwendete Serialisierungsformat mit sortierten Wörterbuchschlüsseln
- Info-Hash: SHA-1 (v1)- oder SHA-256 (v2)-Digest des bencoded-Informationswörterbuchs, die Identität des Torrents
- Inhaltsadressierbarer Speicher: Daten werden anhand ihres Hashwerts anstatt ihres Speicherorts identifiziert.
- Merkle-Bäume: Hash-Bäume pro Datei in BitTorrent v2 (BEP 52) zur Überprüfung auf Stückebene
- Hybrid-Torrents: einzelne Torrents, die sowohl v1- als auch v2-Strukturen und zwei Info-Hashes enthalten
- Stücklänge und Lagenanzahl: der Zielkonflikt zwischen Metadatengröße und Verifizierungsgranularität
- SHA-1-Kollisionsresistenz: Warum v1-Hashing theoretisch geschwächt ist und v2 auf SHA-256 umsteigt
- Erweiterungsprotokoll (BEP 10): Der Handshake-Mechanismus, der ut_metadata, PEX und andere Erweiterungen ermöglicht
- Metadatenaustausch (BEP 9, ut_metadata): Abrufen des Informationswörterbuchs von Peers in 16-KiB-Blöcken
- Magnet-URI-Schema: ein projektneutrales, hashbasiertes Identifikationsschema mit einer vorläufigen IANA-Registrierung
- MAGMA (Magnetmanifest): das Manifest-Topic-Konzept aus den Multi-Netzwerk-Ursprüngen des Magnet-Schemas
- Auswahl der Magnetdatei (BEP 53): Auswahl bestimmter Dateien innerhalb eines Torrents über den Link selbst
- Multitracker-Metadaten (BEP 12): Ankündigungslistenstufen mit Mischen und Failover
- UDP Tracker-Protokoll (BEP 15): Leichtgewichtiger Tracker kündigt über UDP an
- Kompakte Peerlisten (BEP 23): die kompakte Binärkodierung von Peers in Tracker-Antworten
- IPv6-Tracker-Erweiterung (BEP 7): peers6 kündigt Unterstützung für IPv6 an
- Tracker-Berichtswesen externer IP-Adressen (BEP 24): Tracker teilen ihren Kunden die beobachtete Adresse mit
- Mainline DHT (BEP 5): Die auf Kademlia basierende verteilte Hashtabelle zur trackerlosen Peer-Erkennung
- DHT-Sicherheitserweiterung (BEP 42): Einschränkung der Knoten-IDs zum Schutz vor Sybil- und Routing-Tabellenangriffen
- DHT put/get und Infohash-Indexierung (BEP 44, BEP 51): Daten speichern und Info-Hashes im DHT abfragen
- Peer-Exchange, PEX (BEP 11): Schwarmmitglieder teilen Peer-Listen direkt
- Lokale Diensterkennung (BEP 14): Gleichgesinnte im selben Netzwerksegment finden
- Schnelle Erweiterung (BEP 6): Protokollabkürzungen wie have-all, have-none und reject
- uTP (BEP 29): ein UDP-basierter Transport mit verzögerungsbasierter Staukontrolle
- Lochstanzverlängerung (BEP 55): NAT-Traversal koordiniert durch Relaying-Peers
- Nachrichtenstromverschlüsselung (MSE/PE): Protokollverschleierung, nicht Anonymität
- Private Torrents (BEP 27): die private Flagge, die die Peer-Erkennung auf den Tracker beschränkt
- Web-Seeding (BEP 17, BEP 19): HTTP- oder FTP-Server, die als permanente Startpunkte fungieren
- Padding-Dateien (BEP 47): Ausrichtung von Dateien an Segmentgrenzen zur Deduplizierung und Hybridunterstützung
- Hinweise zu lokalen Daten (BEP 38): Daten aus verwandten Torrents wiederverwenden, um erneutes Herunterladen zu vermeiden
- Torrent-Signierung (BEP 35): Eingebettete RSA-Signaturen mit optionalen X.509-Zertifikaten
- Torrent-Update-Feeds (BEP 39): Update-URL für signierte, automatische Nachfolge-Torrents
- Prüfprozess für Einzelteile: Hash-Prüfung vor dem Commit und Wiederherstellung nach fehlgeschlagenen Teilen
- Härtung von Parser und Client: strikter Bencode ValidierungGrößenbeschränkungen, Pfadbereinigung, SSRF-Filterung
- WebTorrent und WebRTC: Browserbasierte Peers, die ws/wss-Tracker und ICE oder TURN verwenden
- Saatgutkästen und Langzeitsaat: Infrastruktur für Verfügbarkeit und Archivierung
- BEP-Prozess und Governance: wie Spezifikationen vorgeschlagen, indexiert und von der Annahme- zur Endfassung befördert werden
- Alternative inhaltsadressierte Systeme: IPFS-ähnliche Inhaltskennungen als vergleichbares Modell
- Herkunft versus Integrität: Warum verifizieren Hashes Daten, aber niemals den Herausgeber?
Externe Links auf Torrent
(Bewegen Sie den Mauszeiger über den Link, um unsere Inhaltsbeschreibung anzuzeigen)
