
A .torrent file and a aimant link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- Un fichier .torrent est un fichier « métadonnées ». Cette extension transfère uniquement la partie info-dictionnaire du fichier .torrent, par blocs de 16 Ko. doit Le client le vérifie ensuite par rapport au hachage du lien.
- Un lien magnet ne contient aucune métadonnée, seulement cette identité. Son format est magnet:?xt=urn:btih: pour la v1 ou xt=urn:btmh: pour la v2, avec les paramètres facultatifs de nom d'affichage (dn), de suivi (tr) et d'adresse homologue (x.pe).
Les deux formats pointent donc vers le même essaim et proposent le même téléchargement une fois lancé. Ils diffèrent par la provenance des métadonnées :
Un fichier .torrent est un artefact statique : la liste des fichiers est connue immédiatement, les métadonnées survivent à la disparition d’un essaim et le fichier doit être hébergé quelque part.
Un lien magnet est une courte chaîne de caractères que l'on peut coller n'importe où, mais il ne fonctionne que si au moins un pair accessible possède encore les métadonnées. Aucun de ces formats n'authentifie l'éditeur ni ne confirme que le contenu correspond à son libellé. Le hachage prouve seulement que les données correspondent au hachage.
Conseil: À la demande générale, cet article sert de support à tous nos articles sur les torrents et le P2P pour l'ingénierie.
Histoire et contexte
Le format .torrent est issu de la conception originale de BitTorrent. Bram Cohen a conçu le protocole en avril 2001 et a publié la première version le 2 juillet 2001. En 2004, il a fondé, avec Ashwin Navin, BitTorrent, Inc. (devenue par la suite Rainberry, Inc.). Cohen est également l'un des auteurs de la BEP 3, la spécification de base qui définit le fichier de métadonnées et le hachage d'informations. Le développement ultérieur est coordonné par le biais du processus des propositions d'amélioration de BitTorrent (BEP), inspiré des PEP de Python. Cohen souhaitait que le client principal reste open source.
Si le lien ne nomme aucun tracker, le client doit utiliser le DHT pour trouver des pairs. format de fichierbep 0009 +2
In practice, both formats rest on the BEP process and on what the major clients implement, not on a formal normes body.
1. Principes fondamentaux
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Qu'est-ce que c'est | Un petit fichier binaire (dictionnaire encodé en bengali) | Un URI de texte (magnet:?xt=urn:btih:…) |
| Contient le contenu ? | Non, seulement les métadonnées | Non, seulement un identifiant |
| Contenu principal | URL(s) du traqueur, noms et tailles des fichiers, longueur des fragments, hachage de chaque fragment, commentaire facultatif, créateur et date | Info-hash (xt), nom d'affichage optionnel (dn), traqueurs (tr), adresses des pairs (x.pe) ; les graines Web (ws) uniquement en tant qu'extension dépendante du client, non définies dans BEP 9 |
| Taille typique | De quelques Ko à plusieurs Mo (augmente avec la taille du contenu) | Environ 100 à 500 octets |
| Identifiant utilisé | SHA-1 info-hash (v1), SHA-256 (v2) ou les deux (hybride) | The same info-hash: urn:btih (v1) or urn:btmh (v2) |
| Spécification | BEP 3 (v1), BEP 52 (v2) | BEP 9 (échange de métadonnées et format d'URI magnétique) |
| Gestionnaire de protocole | Ouvert par association de fichiers (.torrent) | Ouvert par le système d'exploitation ou le navigateur (aimant) : gestionnaire d'URI |
2. Métadonnées et informations sur les fichiers
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Liste des fichiers visible avant le début du téléchargement | Oui, immédiatement | Non, seulement après la récupération des métadonnées auprès des pairs. |
| Source de métadonnées | Intégré dans le fichier | Téléchargé depuis les pairs (DHT, PEX, trackers) via ut_metadata |
| Intégrité des métadonnées | Vérifié par hachage | Vérifié par rapport au hachage d'information du lien ; les métadonnées altérées sont donc rejetées. |
| Délai de démarrage | Aucun | Quelques secondes à quelques minutes (ou jamais, si aucun pair ne possède les métadonnées). |
| Nom d'affichage | Stocké dans le fichier (nom) | Le nom de domaine (DN) est facultatif et non vérifié ; il ne s’agit que d’une étiquette. |
| Hachages de pièces | Compris | Obtenu ultérieurement avec les métadonnées |
| Modifiable | Les trackers peuvent être modifiés sans changer le hachage. Modifier le dictionnaire d'informations change le hachage des informations, créant ainsi un torrent différent. | Facile à modifier comme du texte (ajouter ou supprimer des traqueurs). L'info-hash ne peut être modifié sans pointer vers un contenu différent. |
3. Auteur, provenance et authenticité
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Informations sur l'auteur | Champs facultatifs : créé par (client et version), date de création, commentaire | Aucun ; il n’existe pas de champ auteur standard. |
| Fuite de métadonnées concernant le créateur | Possible (version du client, horodatage, parfois commentaires ou URL) | Minimal ; le lien ne contient que ce que la personne qui le partage a inclus |
| Signature numérique | Une extension de signature existe (BEP 35), mais elle est rarement utilisée. | Aucun |
| Preuve que le contenu correspond à ce qui est indiqué sur l'étiquette | Aucun, et le nom peut être falsifié. | Aucun, et dn peut être falsifié |
| Preuve que le contenu correspond au hachage | Oui, chaque élément est vérifié par hachage. | Yes, every piece is hash-verified after metadata vérification |
| Modèle de confiance | Vous faites confiance à la personne qui a fourni le fichier, puis vous vérifiez les données par rapport aux hachages. | Vous faites confiance à la personne qui vous a fourni le lien, puis vous vérifiez de la même manière. |
| Risque d'usurpation d'identité | Les faux torrents portant le même titre sont courants. | Pareil, et le lien est encore moins contextualisé (aucune liste de fichiers à consulter au préalable). |
4. Hébergement, distribution et disponibilité
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Nécessite un hébergement | Oui, un serveur web, un site d'indexation ou un partage de fichiers. | Non, ce n'est que du texte et on peut le coller n'importe où. |
| Méthodes de partage | Téléchargement, envoi par courriel en pièce jointe, transfert de fichiers (les pièces jointes sont parfois bloquées) | Messagerie instantanée, corps d'e-mail, code QR, message sur un forum, application de notes |
| Exposition de la mise hors service | Les fichiers hébergés peuvent être supprimés ou bloqués. | Plus difficile à supprimer (texte brut), mais les sites qui les publient peuvent tout de même être bloqués. |
| Lien corrompu | Le fichier subsiste tant que l'hôte le fait. | Le texte existe toujours, mais il est inutile si aucun pair ne possède encore les métadonnées. |
| Valeur d'archivage | Avantage élevé : il préserve l’intégralité des métadonnées même lorsque l’essaim est détruit. | Faible : dépend d'un essaim actif pour récupérer les métadonnées |
| Sites d'indexation et de recherche | Il faut stocker un fichier par torrent (plus d'espace de stockage) | Ne stockez qu'une courte chaîne de caractères (moins cher et plus facile à dupliquer). |
| Utilisation multi-appareils | Nécessite un transfert de fichier | Facile : copiez et collez, ou scannez un code QR |
| Comportement du navigateur | Télécharge un fichier, puis l'ouvre dans un client | Déclenche une invite de gestionnaire de protocole (nécessite un client enregistré) |
5. Comportement et performances du réseau
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| découverte par les pairs | Les trackers listés dans le fichier, plus DHT, PEX et LSD (sauf en cas de distribution privée). | DHT, PEX et LSD, ainsi que tous les trackers tr du lien |
| Fonctionne sans aucun traqueur | Uniquement si la DHT est autorisée | Oui, avec la DHT (c'est son mode habituel). |
| Dépendance à la DHT | Facultatif | Souvent essentiel pour les métadonnées et les pairs |
| Semences Web (sources HTTP) | liste d'URL / champs httpseeds (BEP 19) | ws= paramètre, une extension dépendante du client non définie dans BEP 9 |
| Vitesse de téléchargement une fois lancé | Identique | |
| Comportement avec les torrents morts ou rares | Il démarre et attend ses pairs. | Peut bloquer à « la récupération des métadonnées » |
| traqueurs privés | Entièrement pris en charge (indicateur privé, clé d'accès dans l'URL d'annonce) | Généralement inutilisable. Les torrents privés désactivent DHT/PEX et la clé d'accès du tracker n'est pas accessible via un lien partageable. |
6. Sécurité
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Source de risque de logiciels malveillants | Le contenu téléchargé, et non le format. | Le contenu téléchargé, et non le format. |
| Risque lié à l'analyseur ou au gestionnaire | Un bencode malformé peut déclencher des bogues dans un client mal écrit (rare). | Des paramètres DN ou URI malveillants peuvent provoquer des erreurs d'injection ou d'affichage dans des clients ou des gestionnaires mal conçus (rare). |
| Possibilité de vérifier avant de télécharger | Niveau élevé : vous pouvez voir en premier la liste des fichiers, leurs extensions et leurs tailles. | Faible jusqu'à l'arrivée des métadonnées ; la plupart des clients vous permettent ensuite de consulter la liste des fichiers avant de les télécharger. |
| Exécutables déguisés | Détectable dans la liste des fichiers (.exe, .scr, .lnk, etc.) | Pareil, mais seulement après la récupération des métadonnées. |
| Risques liés à l'hameçonnage et à la publicité | Les sites de torrents sont souvent remplis de publicités. | Pareil, plus des clics accidentels sur des boutons magnétiques similaires |
| Force du haschisch | SHA-1 pour la v1 (faible en termes de collisions en théorie, difficile à exploiter pour les torrents) ; SHA-256 pour la v2 | Même hachage que le torrent auquel il fait référence |
| Altération en cours de transport | Détecté via les hachages de morceaux | Détecté via le hachage d'informations, bien qu'un lien inversé pointe vers un contenu totalement différent. |
7. Confidentialité et anonymat
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Votre adresse IP est visible par vos pairs. | Oui | |
| Votre adresse IP est visible par les traqueurs. | Oui (traceurs intégrés) | Oui, si les trackers tr sont inclus |
| exposition au DHT | Possible | C’est presque certain ; vos recherches sont effectuées sur le DHT public. |
| Différence d'anonymat | Aucun significatif | |
| Métadonnées révélant l'auteur du partage | L'auteur, le commentaire et la date de création peuvent révéler des détails. | Rien de plus que ce que contient le texte du lien |
| mesures d'atténuation | VPN or procuration, client-side cryptage, private trackers | |
8. Risques et limitations
| Risque | fichier .torrent | Lien magnétique |
|---|---|---|
| Des stands sans équivalent | Attend ses pairs | Il est possible que nous n'obtenions jamais de métadonnées |
| Contenu faux ou mal étiqueté | Possible | |
| Risque juridique | Cela dépend du contenu et de la juridiction. L'hébergement du fichier peut accroître la visibilité des opérateurs de sites. | Cela dépend du contenu et de la juridiction. Le partage de liens est parfois traité différemment de l'hébergement de fichiers, mais cela varie et ne constitue pas une garantie absolue. |
| exposition à la vie privée | Suivi et visibilité des pairs | DHT et visibilité entre pairs |
| Traqueur mort | Réduit les chances de découverte, mais le DHT peut toujours fonctionner. | Pas de problème si la liaison repose sur le DHT |
| durabilité à long terme | Mieux | Pire |
| Fautes de frappe et troncature | Un fichier corrompu a été détecté. | Une faute de frappe dans le hachage ne mène à rien, et un lien tronqué est rompu sans avertissement. |
9. Compatibilité et facilité d'utilisation
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Assistance clientèle | Universel | Universel chez les clients modernes (nécessite BEP 9) |
| Seedboxes et services web | Soutien universel | La plupart des services sont pris en charge, bien que certains services plus anciens n'acceptent que les fichiers. |
| Compatibilité mobile | Modéré (la gestion des fichiers téléchargés est maladroite) | Haut |
| Automation (RSS, scripts, APIs) | Direct | Également simple et plus facile à stocker |
| Lisibilité humaine | Illisible sans outil | Le hachage est opaque, mais la structure est lisible. |
10. Comment créer des fichiers .torrent et des liens Magnet
Les éléments marqués d'un poignard sont le fruit de mon propre raisonnement ou de mes connaissances générales, et non confirmés par une source.
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Entrée initiale | Vos fichiers ou dossiers réels, plus un outil de création (par exemple mktorrent, ou la fonction « créer un torrent » d'un client). | Un hachage d'informations existant. Dans la version 1, il s'agit du SHA-1 du dictionnaire d'informations encodé ; par conséquent, un lien magnet ne peut exister avant que les métadonnées .torrent ne soient présentes. |
| Ordre des étapes | 1) Choisir la longueur des morceaux. 2) Hacher chaque morceau. 3) Construire le dictionnaire d'informations. 4) Ajouter des champs externes tels que les trackers. 5) Bencoder et enregistrer. | 1) Récupérez le torrent. 2) Récupérez son info-hash. 3) Écrivez l'URI avec xt. 4) Ajoutez éventuellement dn, tr et x.pe |
| Longueur de la pièce | Vous choisissez la taille. C'est presque toujours une puissance de deux, le plus souvent 256 Kio. mktorrent utilise par défaut 2^18 octets et vous pouvez la définir avec l'option -l. | Aucun ; il est hérité du torrent |
| Travail de hachage | Chaque octet est haché : par morceaux SHA-1 pour la v1, par arbres de Merkle SHA-256 par fichier pour la v2. Le temps d’exécution augmente avec la taille des données (dagger), et mktorrent peut utiliser plusieurs threads. | Négligeable : rien au-delà du hachage existant |
| Traqueurs | annonce, ou liste d'annonces. Cette liste se trouve en dehors de la section d'informations ; si elle est présente, les clients compatibles ignorent l'annonce et les niveaux sont testés dans l'ordre, les URL au sein d'un même niveau étant mélangées. | tr = paramètres dans l'URI. Si aucun n'est fourni, les clients doivent utiliser le DHT |
| pavillon privé | Configurez ce comportement en ajoutant `private=1` au dictionnaire d'informations. Les clients compatibles annonceront alors uniquement leurs informations au tracker privé et se connecteront uniquement aux pairs qu'il leur indiquera. Ces informations étant internes, elles affectent le hachage des informations (dagger). | Aucun champ n'est prévu à cet effet dans le lien. L'indicateur se trouve dans les métadonnées, que le client ne voit qu'après les avoir récupérées (dagger). |
| Graines Web | Liste d'URL, conformément à la BEP 19. mktorrent l'expose avec l'option -w. Le serveur HTTP/FTP agit comme un seed permanent non bridé. | ws= ne fait pas partie de la liste des paramètres de BEP 9. Considérez-le comme une extension dépendante du client. |
| champs descriptifs facultatifs | Le commentaire et la date de création sont facultatifs. mktorrent propose l'option -c pour ajouter un commentaire et l'option -d pour omettre la date. | DN (nom d'affichage) uniquement. Il s'agit d'une étiquette non vérifiée. |
| Balise source | L'option `-s` de mktorrent intègre une chaîne de caractères source dans l'info-hash. Ainsi, des fichiers identiques avec une étiquette différente reçoivent un hachage différent et un swarm distinct. | Non applicable |
| Qu'est-ce qui change l'identité ? | Informations internes : nom, longueur du morceau, indicateur privé, étiquette source, liste des fichiers (dagger) | Modifier l'extension xt pointe vers un autre torrent. Modifier l'extension dn, tr ou x.pe ne change rien. |
| choix de version de hachage | v1 (SHA-1), v2 (SHA-256) ou hybride, choisi lors de la création | Le lien doit contenir btih, btmh, ou les deux pour un torrent hybride (BEP 9 autorise les deux sujets dans un seul lien magnétique s'ils décrivent le même torrent hybride). |
| Signature | Le protocole BEP 35 autorise l'intégration de signatures RSA dans le fichier, éventuellement avec un certificat X.509, et plusieurs signatures par torrent. Il est rarement utilisé (dagger). | La norme BEP 9 ne définit aucun champ de signature, il n'y a donc rien à signer. |
| Sortir | Un fichier binaire de Ko à Mo, que vous devez héberger ou envoyer | Une ligne de texte de quelques centaines d'octets |
| Le rendre utilisable | Téléversez le fichier et exécutez un client avec les données d'origine afin de pouvoir l'initialiser. | Publiez la ligne et continuez à la partager. Le lien est inutile si aucun pair ne possède les données et les métadonnées. |
| erreurs typiques | Taille de segment inadaptée à la taille du contenu (dagger) ; oubli de l'indicateur de confidentialité avant publication, car sa modification ultérieure entraîne la génération d'un nouveau hachage (dagger) ; ajout d'un tracker incorrect | Erreur de frappe ou troncature dans le hachage, le lien ne pointe donc nulle part (♭) ; préfixe incorrect (btih au lieu de btmh) ; caractères spéciaux non échappés dans le nom de domaine (♭). |
11. En utilisant chacun
Les éléments marqués d'un poignard sont le fruit de mon propre raisonnement ou de mes connaissances générales, et non confirmés par une source.
| Aspect | fichier .torrent | Lien magnétique |
|---|---|---|
| Comment l'ouvrir | Double-cliquez dans l'association de fichiers, faites-le glisser dans un client ou utilisez « Ajouter un fichier torrent ». | Cliquez sur un lien magnétique (nécessite un gestionnaire enregistré), collez-le dans un client ou scannez un code QR (dagger). |
| Ce que le client fait en premier | Analyse les métadonnées encodées | Analyse l'URI et extrait le hachage d'informations |
| D'où proviennent les métadonnées ? | Déjà dans le fichier | Les pairs envoient le dictionnaire d'informations (uniquement cette partie du fichier .torrent) par blocs de 16 KiB via l'extension BEP 9, et le client le vérifie par rapport au hachage. |
| Trouver des pairs | Les trackers du fichier, ainsi que DHT/PEX/LSD, sauf si le torrent est privé. Pour les torrents privés, DHT et PEX ne doivent pas être utilisés. | Traceurs dans le lien ; sinon, le DHT |
| Délai de démarrage | Aucun | Attendre la réponse d'un pair possédant les métadonnées, ce qui peut entraîner un blocage indéfini. |
| Sélectionner les fichiers avant le téléchargement | Immédiatement | Une fois les métadonnées reçues. Certains clients peuvent récupérer uniquement les métadonnées, afin de prévisualiser la liste des fichiers avant de les télécharger. |
| Inspection avant validation | Inspection complète avec n'importe quel outil d'analyse syntaxique, hors ligne | Impossible tant que les métadonnées n'ont pas été récupérées. |
| Conversion entre eux | Calculez le hachage d'information et écrivez un lien magnétique (dagger). | Les métadonnées récupérées peuvent être exportées et mises en cache sous forme de torrent, ce qui évite de devoir télécharger une seconde fois les métadonnées d'un même lien magnétique. |
| Utilisation de traqueurs privés | Cela fonctionne, puisque le fichier contient l'URL du traqueur et que les clients doivent se limiter à celle-ci (BEP 27). | Probablement impraticable : le lien ne comporte aucun indicateur, et une URL de traqueur peut contenir des informations d’identification personnelles (dagger). Le document BEP 27 n’aborde pas la question des aimants. |
| Édition | Ajoutez ou supprimez des trackers sans modifier le hachage, car ils ne figurent pas dans la section d'informations. Modifier les informations crée un nouveau torrent. | Modifiez librement le texte ; modifier xt change le torrent en question. |
| Vérification de l'authenticité | Vérifiez la signature BEP 35 par rapport à un certificat de confiance. Une bibliothèque précise que sa vérification ne valide pas le certificat lui-même. Sinon, consultez la liste des fichiers. | Comparez le hachage d'information avec celui d'une source fiable ; aucune autre information n'est disponible. |
| Mises à jour automatiques | BEP 39 permet à un créateur d'inclure une URL de mise à jour dans le dictionnaire d'informations, et les clients téléchargent automatiquement les torrents les plus récents uniquement s'ils sont signés par l'auteur. | Aucun |
| Poursuivre le partage | Envoyer ou héberger le fichier | Copiez et collez la ligne |
| Quand cela échoue | Tracker inactif ou sans pairs : le client attend. Un fichier corrompu est rejeté. | Erreur de frappe dans le hachage ou pair injoignable : bloqué sur « récupération des métadonnées » |
| Sauvetage de graines Web | Un fichier .torrent avec un lien web de départ fonctionne même sans pairs. Les liens Magnet n'ont pas d'équivalent, car ni BEP 9 ni les BEP de départ HTTP ne permettent de récupérer les métadonnées des liens HTTP. | |
| Après le téléchargement | Continuez à partager les mêmes fichiers | |

Résumé
Les fichiers torrent (.torrent) sont idéaux pour l'archivage, les trackers privés, la consultation préalable de la liste des fichiers et les métadonnées hors ligne, tandis que les magnets excellent dans le partage rapide, les codes QR, la distribution indépendante des trackers et l'hébergement minimal.
Aucun des deux formats n'est intrinsèquement plus sûr. Tous deux vérifient l'intégrité des données par cryptographie, mais aucun n'authentifie l'auteur du contenu ni sa nature exacte. Le véritable risque, tant juridique que sécuritaire, provient du contenu lui-même et de sa source. Il est donc important de vérifier la liste des fichiers et de repérer les extensions suspectes, ainsi que la provenance du lien.
FAQ
BitTorrent est-il une norme IETF ou ISO, et quel est le statut officiel des fichiers .torrent et des liens magnétiques ?
Non. Le protocole est spécifié par les BitTorrent Enhancement Proposals (BEP), un processus inspiré des PEP de Python. La BEP 3 définit le format des métadonnées et la BEP 52 définit la version 2. La BEP 9, qui couvre l'échange de métadonnées et le format magnet de BitTorrent, a le statut « Accepté », et non « Final ». Le schéma magnet: n'est qu'un enregistrement IANA provisoire, créé par le projet Magnet-URI. En pratique, l'interopérabilité est définie par les principales bibliothèques clientes ; il est donc conseillé de tester avec plusieurs implémentations.
L'info-hachage lie-t-il cryptographiquement un torrent à son contenu ?
Transitivement, oui. Le hachage d'informations v1 est le SHA-1 du dictionnaire d'informations encodé, et ce dictionnaire contient le hachage SHA-1 de chaque élément ; le hachage est donc lié aux données. Le problème réside dans la faible résistance aux collisions de SHA-1 : des collisions pratiques existent, de sorte qu'un éditeur qui crée les deux variantes d'un torrent pourrait concevoir deux charges utiles avec un seul hachage. Les attaques par seconde préimage contre un torrent existant restent impossibles. La v2 utilise SHA-256 et élimine ce problème.
Quelles modifications changent l'identité d'un torrent et lesquelles ne le font pas ?
Toute modification apportée au dictionnaire d'informations change l'info-hash : nom, liste des fichiers, longueur des morceaux, indicateur de confidentialité et étiquette source (comme l'option `-s` de mktorrent). Les champs extérieurs, tels que `announce` et `announce-list` (BEP 12), peuvent être modifiés librement sans créer de nouveau torrent. Dans un lien magnet, `dn`, `tr` et `x.pe` n'affectent jamais l'identité ; seul `xt` a un impact. Modifier le dictionnaire d'informations crée une branche silencieuse du swarm ; considérez donc cette action comme la publication d'un nouveau torrent.
Comment un client authentifie-t-il les métadonnées reçues via un lien magnet ?
Les pairs envoient le dictionnaire d'informations par blocs de 16 Kio via l'extension BEP 9 ut_metadata. Le client hache le résultat assemblé et le compare au hachage d'informations du lien. Les métadonnées falsifiées sont rejetées, sauf si l'attaquant parvient à casser le hachage. Ceci prouve l'intégrité par rapport au lien, et non la véracité. La valeur dn est une étiquette non vérifiée, et le hachage ne renseigne ni sur l'auteur du contenu, ni sur son contenu réel.
Quelles sont les différences pratiques entre les torrents v1, v2 et hybrides ?
La version 1 utilise une liste plate de hachages SHA-1 dans le dictionnaire d'informations. La version 2 (BEP 52) utilise SHA-256 avec un arbre de Merkle par fichier et une arborescence de fichiers hiérarchique. Les couches de fragments sont situées en dehors du dictionnaire d'informations et les implémentations doivent les vérifier par rapport aux champs racines des fragments à l'intérieur de celui-ci. Un torrent hybride contient les deux structures et possède donc deux hachages d'informations ; un lien magnétique peut contenir à la fois des sujets btih et btmh. Assurez-vous que votre client et vos outils prennent en charge la version 2 avant de publier des torrents ne contenant que la version 2.
Un lien magnétique peut-il lancer un téléchargement lorsqu'il n'y a pas d'utilisateurs pairs mais qu'une source web HTTP existe ?
Non. BEP 9 récupère les métadonnées uniquement auprès des pairs, et ni BEP 9 ni les BEP de partage HTTP (17, 19) ne définissent de méthode pour récupérer les métadonnées d'un lien HTTP. Un fichier .torrent avec un lien web fonctionne même sans pairs, car les métadonnées sont déjà incluses dans le fichier. Si vous comptez sur les liens web pour la disponibilité, distribuez le fichier .torrent, et non un simple lien magnétique.
Que révèle chaque format sur ma vie privée et mon identité en réseau ?
Les deux exposent votre adresse IP à vos pairs et aux trackers auxquels vous vous annoncez. Les liens Magnet dépendent généralement du DHT public, ce qui ajoute un chemin de résolution supplémentaire où apparaissent votre adresse IP et le hachage d'information. Le chiffrement du protocole masque le trafic, mais ne vous anonymise pas. Les torrents privés (BEP 27) exigent que les clients utilisent uniquement le tracker privé ; le DHT et PEX ne sont donc pas utilisés. Pour garantir votre anonymat, privilégiez un modèle de gestion des menaces avec des mesures d'atténuation appropriées au niveau du réseau, plutôt qu'un choix de format.
Comment puis-je vérifier l'authenticité, et pas seulement l'intégrité, des données obtenues via torrent ?
La vérification des fichiers ne fait que confirmer leur correspondance avec le torrent. Pour garantir leur authenticité, obtenez une somme de contrôle ou une signature (par exemple, un manifeste SHA-256 signé) via un canal de confiance indépendant et comparez-la aux fichiers finaux. La norme BEP 35 définit des signatures RSA intégrées aux fichiers .torrent, avec des certificats X.509 optionnels et la possibilité d'utiliser plusieurs signataires. Cependant, elle est rarement déployée, et une bibliothèque l'implémentant précise que sa vérification ne valide pas le certificat lui-même. Les liens Magnet, quant à eux, ne disposent d'aucun mécanisme de signature.
Comment choisir la longueur des morceaux lors de la création d'un torrent ?
Il s'agit d'un compromis entre la taille des métadonnées et la granularité des transferts. La norme BEP 3 stipule que la longueur des morceaux est presque toujours une puissance de deux, généralement 256 Kio, valeur par défaut de mktorrent. Dans la version 1, une charge utile de 100 Gio de 256 Kio comporte 409 600 morceaux, soit environ 8 Mo pour la chaîne de caractères des morceaux. Les clients Magnet doivent télécharger l'intégralité de ce dictionnaire en environ 500 blocs avant de démarrer ; des métadonnées trop volumineuses ralentissent donc le démarrage des transferts Magnet. Des morceaux plus longs réduisent la taille des métadonnées, mais rendent la réparation après une défaillance de morceau plus grossière.
Pourquoi deux flux de données identiques se retrouvent-ils dans des essaims distincts, et comment puis-je éviter cela ?
L'info-hash couvre l'intégralité du dictionnaire d'informations. Des noms, un ordre de fichiers, des longueurs de fragments, des indicateurs privés ou des étiquettes de source différents produisent des info-hash différents, même pour des charges utiles identiques octet par octet. Pour maintenir un seul essaim, standardisez la longueur des fragments, le nom, l'ordre des fichiers et les indicateurs lors de votre processus de publication, et publiez l'info-hash avec l'artefact. Les étiquettes de source sont un moyen intentionnel de séparer les essaims, et l'option `-s` de mktorrent modifie délibérément l'info-hash.
Quels sont les principaux problèmes de sécurité à prendre en compte lors de la conception d'un client ou d'un analyseur syntaxique pour ces formats ?
Considérez toutes les données d'entrée comme non fiables. Validez rigoureusement le format bencode, limitez la taille des métadonnées (un client open source impose une limite de 32 Mo) et nettoyez les chemins de fichiers dans les métadonnées afin d'empêcher les attaques par traversée de répertoires. Filtrez les adresses privées et de bouclage renvoyées par les traqueurs et le DHT pour limiter les abus de type SSRF et vérifiez que les URL des traqueurs sont acceptables avant de vous connecter. Traitez le nom distinctif (DN) comme du texte non fiable et vérifiez le hachage de chaque fragment avant de l'écrire dans le stockage final.
Comment calculer correctement un hachage d'informations à partir d'un fichier .torrent ?
Repérez la plage d'octets exacte contenant la valeur d'information dans le fichier, puis hachez ces octets : SHA-1 pour v1 ou SHA-256 pour v2. BEP 3 insiste sur le fait que le hachage est appliqué à l'encodage présent dans le fichier. Le décodage et le réencodage du dictionnaire ne sont sûrs que si le décodeur a entièrement validé l'entrée ; un décodeur permissif peut normaliser les données silencieusement et produire un hachage différent. Pour les torrents hybrides, calculez les deux hachages à partir de la même plage d'octets.
Puis-je utiliser un lien magnet pour un torrent provenant d'un tracker privé ?
En pratique, c'est souvent impossible. La BEP 27 exige que les clients annoncent uniquement leur connexion au tracker privé et se connectent uniquement aux pairs qu'il leur renvoie. Un lien magnet nu ne contient aucun indicateur de confidentialité, car celui-ci réside dans les métadonnées, et peut ne pas inclure d'URL de tracker utilisable. Si une URL de tracker contenant des identifiants est intégrée, traitez le lien comme un secret. C'est ce que je déduis de la spécification, car la BEP 27 n'aborde pas directement les liens magnet ; il est donc conseillé de tester avec les règles de votre tracker.
Pour la distribution de logiciels, d'ensembles de données ou d'archives dans un pipeline, dois-je publier un fichier .torrent ou un lien magnet ?
Publiez les deux fichiers, le fichier .torrent étant l'artefact principal. Il préserve l'intégralité des métadonnées, permet aux utilisateurs de consulter la liste des fichiers hors ligne et prend en charge les seeders web (BEP 19) pour garantir sa disponibilité. Générez le lien magnet à partir du même hachage d'informations pour plus de simplicité, et publiez ce hachage ainsi qu'une somme de contrôle signée sur un canal de confiance. Ceci assure la pérennité de l'archivage et facilite le partage sans que la récupération des métadonnées dépende des pairs.
Qu'est-ce qui détermine la durée de disponibilité d'un torrent, et comment puis-je l'améliorer ?
La récupération des données nécessite au moins un pair accessible les détenant, et pour les liens magnétiques, un pair détenant également les métadonnées. Améliorez-la en maintenant les seeders actifs, en ajoutant plusieurs trackers hiérarchisés (BEP 12) comme sauvegarde, en ajoutant des seeders web HTTP et en conservant le fichier .torrent archivé ou exportable depuis les clients qui mettent en cache les métadonnées récupérées. Un lien magnétique seul ne préserve rien ; un essaim inactif le rend donc inutilisable.
Liste étendue de lectures et de sujets connexes
- Bencoding : le format de sérialisation utilisé par les fichiers .torrent, avec des clés de dictionnaire triées
- Info-hash : Digest SHA-1 (v1) ou SHA-256 (v2) du dictionnaire d'informations encodé, l'identité du torrent
- Stockage adressable par contenu : identifier les données par leur hachage plutôt que par leur emplacement
- Arbres Merkle : Arbres de hachage par fichier dans BitTorrent v2 (BEP 52) pour la vérification au niveau des morceaux
- Torrents hybrides : torrents uniques contenant à la fois des structures v1 et v2 et deux hachages d'information
- Longueur et nombre de couches des pièces : le compromis entre la taille des métadonnées et la granularité de la vérification
- résistance aux collisions SHA-1 : Pourquoi le hachage v1 est théoriquement affaibli et le v2 passe à SHA-256
- Protocole d'extension (BEP 10) : le mécanisme de prise de contact qui permet l'utilisation de ut_metadata, PEX et d'autres extensions
- Échange de métadonnées (BEP 9, ut_metadata) : Récupération du dictionnaire d'informations auprès des pairs par blocs de 16 KiB
- Schéma d'URI Magnet : un système d'identifiants neutre vis-à-vis des projets, basé sur le hachage et bénéficiant d'un enregistrement IANA provisoire
- MAGMA (manifeste magnétique) : le concept de sujet manifeste issu des origines multi-réseaux du schéma magnétique
- Sélection du fichier Magnet (BEP 53) : choisir des fichiers spécifiques à l'intérieur d'un torrent à partir du lien lui-même
- Métadonnées Multitracker (BEP 12) : niveaux de liste d'annonces avec brassage et basculement
- UDP tracker protocol (BEP 15): Annonce d'un traqueur léger via UDP
- Listes de pairs compactes (BEP 23) : l'encodage binaire compact des pairs dans les réponses du traqueur
- Extension de suivi IPv6 (BEP 7) : peers6 prend en charge IPv6 annonce
- Signalement des adresses IP externes du tracker (BEP 24) : traqueurs informant les clients de leur adresse observée
- DHT principale (BEP 5) : table de hachage distribuée basée sur Kademlia pour la découverte de pairs sans traqueur
- Extension de sécurité DHT (BEP 42) : restreindre les identifiants de nœuds pour résister aux attaques Sybil et aux attaques par manipulation de tables de routage
- Opérations de mise en écriture/récupération DHT et indexation infohash (BEP 44, BEP 51) : stockage des données et des hachages d'informations d'échantillonnage dans le DHT
- Échange entre pairs, PEX (BEP 11) : Les membres de l'essaim partagent directement leurs listes de pairs
- Découverte de services locaux (BEP 14) : trouver des pairs sur le même segment de réseau
- Prolongation rapide (BEP 6) : raccourcis de protocole tels que tout avoir, rien avoir et rejeter
- uTP (BEP 29) : un système de transport basé sur UDP avec contrôle de congestion basé sur le délai
- Extension de perforation (BEP 55) : Traversée NAT coordonnée par des pairs relais
- Chiffrement du flux de messages (MSE/PE) : Obfuscation du protocole, et non anonymat
- Torrents privés (BEP 27) : le drapeau privé limitant la découverte par les pairs au traqueur
- Ensemencement du Web (BEP 17, BEP 19) : Serveurs HTTP ou FTP faisant office de serveurs permanents
- Fichiers de remplissage (BEP 47) : alignement des fichiers sur les limites des fragments pour la déduplication et la prise en charge hybride
- Indications de données locales (BEP 38) : Réutilisation des données de torrents similaires pour éviter les retéléchargements.
- Signature Torrent (BEP 35) : Signatures RSA intégrées avec certificats X.509 optionnels
- Flux de mise à jour Torrent (BEP 39) : URL de mise à jour pour les torrents signés et successeurs automatiques
- pipeline de vérification des pièces : vérification du hachage avant la validation et récupération des fragments défaillants
- Renforcement du parseur et du client : strict bencode validation, size caps, path sanitization, SSRF filtering
- WebTorrent et WebRTC : pairs basés sur navigateur utilisant des traqueurs ws/wss et ICE ou TURN
- Boîtes à graines et semis à long terme : infrastructure pour la disponibilité et la persistance des archives
- Processus et gouvernance du BEP : Comment les spécifications sont proposées, indexées et promues de la version acceptée à la version finale
- Systèmes alternatifs d'adressage par contenu : Les identificateurs de contenu de type IPFS comme modèle comparable
- Provenance versus intégrité : Pourquoi les hachages vérifient-ils les données mais n'authentifient-ils jamais l'éditeur ?
Liens externes sur Torrent
(survolez le lien pour voir notre description du contenu)

















