A .torrent file and a imán link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- Un archivo .torrent es un archivo de “metainformación”. Su diccionario de información contiene la longitud de la pieza, el nombre y la longitud del archivo (o una lista de archivos) y, en v1, una lista concatenada de hashes SHA-1 de 20 bytes, uno por pieza. El hash de información es el SHA-1 de 20 bytes del valor de información codificado en ben, calculado sobre la forma codificada exactamente como aparece en el archivo .torrent. Las URL de los rastreadores se encuentran fuera de ese diccionario, por lo que se pueden cambiar sin alterar la identidad del torrent. BitTorrent v2 (BEP 52) cambia el hash: utiliza SHA-256 con un árbol Merkle por archivo y un árbol de archivos jerárquico. Las "capas de piezas" por archivo se encuentran fuera del diccionario de información, y las implementaciones debe Compruébalos con los campos raíz de las piezas que contiene. bep 0003 +2
- Un enlace magnético no contiene metadatos, solo esa identidad. Su formato es magnet:?xt=urn:btih: para v1 o xt=urn:btmh: para v2, con parámetros opcionales de nombre para mostrar (dn), rastreador (tr) y dirección del par (x.pe). Un torrent híbrido puede contener temas btih y btmh en un solo enlace. Para empezar, el cliente obtiene los metadatos de otros pares usando la extensión BEP 9. Esta extensión transfiere solo la parte del diccionario de información del archivo .torrent, en bloques de 16 KiB. Luego, el cliente lo compara con el hash del enlace. Si el enlace no menciona ningún rastreador, el cliente debe usar la DHT para encontrar pares. bep 0009 +2
Por lo tanto, ambos formatos apuntan al mismo enjambre y proporcionan la misma descarga una vez que comienza. Se diferencian en la procedencia de los metadatos:
Un archivo .torrent es un artefacto estático: la lista de archivos se conoce de inmediato, los metadatos sobreviven a un enjambre muerto y el archivo tiene que estar alojado en algún lugar.
Un enlace magnet es una cadena corta que se puede pegar en cualquier lugar, pero solo funciona mientras al menos un servidor accesible conserve los metadatos. Ninguno de los formatos autentica al editor ni confirma que el contenido coincida con su etiqueta. El hash solo demuestra que los datos coinciden con el hash.
Consejo: A petición popular, esta publicación sirve de apoyo para todas nuestras publicaciones sobre torrents y P2P para ingeniería.
Historia y antecedentes
El formato .torrent proviene del diseño original de BitTorrent. Bram Cohen diseñó el protocolo en abril de 2001 y lanzó la primera versión el 2 de julio de 2001. Junto con Ashwin Navin, fundó BitTorrent, Inc. (más tarde Rainberry, Inc.) en 2004. Cohen también figura como autor de BEP 3, la especificación principal que define el archivo de metainformación y el hash de información. El desarrollo posterior se coordina mediante el proceso de Propuesta de Mejora de BitTorrent (BitTorrent Enhancement Proposal, PEP), que se inspiró en las PEP de Python, y Cohen deseaba que el cliente principal siguiera siendo de código abierto.
La especificación BEP 3 es lo más parecido a una autoridad formal para la formato de archivoEl formato v2 llegó mucho más tarde: BitTorrent, Inc. publicó la especificación v2 el 15 de mayo de 2017. Los enlaces magnet tienen un origen diferente. El esquema magnet: no se inventó para BitTorrent. Se diseñó como una forma independiente del proyecto para identificar archivos mediante hash de contenido en varias redes P2P. IANA lo cataloga solo como un esquema provisional, registrado en 2012 con el Proyecto Magnet-URI como su creador. Las fuentes secundarias fechan su introducción en 2002, pero no encontré ninguna fuente primaria para esa fecha. El uso de enlaces magnet por parte de BitTorrent se basa en BEP 9, escrito por Greg Hazel y Arvid Norberg (Norberg es también el autor original de libtorrent). BEP 9 aún se considera "Aceptado", no definitivo, y en 2016 incorporó el parámetro de dirección de pares x.pe. Dicho BEP define tanto el protocolo de intercambio de metadatos como el formato magnet de BitTorrent, pero las notas de un implementador describen las URI magnet como una convención de facto, no como un BEP numerado.
En la práctica, ambos formatos se basan en el proceso BEP y en lo que implementan los principales clientes, no en un formato formal. estándares cuerpo.
1. Fundamentos
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Qué es | Un pequeño archivo binario (diccionario codificado con ben) | Un URI de texto (magnet:?xt=urn:btih:…) |
| ¿Contiene el contenido? | No, solo metadatos | No, solo un identificador |
| Contenidos principales | URL(s) del rastreador, nombres y tamaños de archivo, longitud de la pieza, hash de cada pieza, comentario opcional, creador y fecha. | Info-hash (xt), nombre para mostrar opcional (dn), rastreadores (tr), direcciones de pares (x.pe); semillas web (ws) solo como una extensión dependiente del cliente, no definida en BEP 9 |
| Tamaño típico | De unos pocos KB a varios MB (aumenta con el tamaño del contenido) | Aproximadamente entre 100 y 500 bytes |
| Identificador utilizado | Hash informativo SHA-1 (v1), SHA-256 (v2) o ambos (híbrido) | El mismo hash de información: urna:btih (v1) o urn:btmh (v2) |
| Especificación | BEP 3 (v1), BEP 52 (v2) | BEP 9 (intercambio de metadatos y formato URI magnet) |
| Controlador de protocolo | Abierto mediante asociación de archivos (.torrent) | Abierto por el sistema operativo o el navegador magnet: controlador URI |
2. Metadatos e información de archivos
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| La lista de archivos es visible antes de que comience la descarga. | Sí, inmediatamente | No, solo después de que se hayan obtenido los metadatos de los pares. |
| Fuente de metadatos | Incrustado en el archivo | Descargado de pares (DHT, PEX, rastreadores) a través de ut_metadata |
| Integridad de los metadatos | Verificado mediante hash | Verificado con el hash de información del enlace, por lo que se rechazan los metadatos manipulados. |
| Retardo de inicio | Ninguno | De segundos a minutos (o nunca, si ningún otro usuario tiene los metadatos). |
| Nombre para mostrar | Almacenado en el archivo (nombre) | dn es opcional y no está verificado; es solo una etiqueta. |
| hashes de piezas | Incluido | Obtenido posteriormente con los metadatos |
| Editable | Los rastreadores se pueden editar sin cambiar el hash. Editar el diccionario de información cambia el hash de información, creando un torrent diferente. | Es muy sencillo editarlo como texto (añadir o eliminar rastreadores). El hash de información no se puede cambiar sin apuntar a un contenido diferente. |
3. Autor, procedencia y autenticidad
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Información del autor | Campos opcionales: creado por (cliente y versión), fecha de creación, comentario | Ninguno; no hay un campo de autor estándar. |
| Fuga de metadatos sobre el creador | Posible (versión del cliente, marca de tiempo, a veces comentarios o URL) | Mínimo; el enlace contiene solo lo que incluyó quien lo compartió. |
| Firma digital | Existe una extensión de firma (BEP 35), pero rara vez se utiliza. | Ninguno |
| Prueba de que el contenido es lo que dice la etiqueta. | Ninguno, y el nombre puede ser falsificado. | Ninguno, y dn puede ser falsificado |
| Prueba de que el contenido coincide con el hash | Sí, cada pieza está verificada mediante hash. | Sí, cada pieza se verifica mediante hash después de los metadatos. verificación |
| Modelo de confianza | Confías en quien te proporcionó el archivo y luego verificas los datos con los hashes. | Si confías en quien te proporcionó el enlace, verifícalo de la misma manera. |
| Riesgo de suplantación de identidad | Los torrents falsos con el mismo título son comunes. | Lo mismo ocurre con el enlace, que tiene aún menos contexto (no hay una lista de archivos para inspeccionar primero). |
4. Alojamiento, distribución y disponibilidad
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Necesita alojamiento | Sí, un servidor web, un sitio de índice o un recurso compartido de archivos. | No; es solo texto y se puede pegar en cualquier lugar. |
| Métodos para compartir | Descarga, archivo adjunto de correo electrónico, transferencia de archivos (en ocasiones, los archivos adjuntos están bloqueados). | Chat, cuerpo del correo electrónico, código QR, publicación en foro, aplicación de notas |
| Exposición de eliminación | Los archivos alojados pueden ser eliminados o bloqueados. | Es más difícil eliminarlos (texto plano), pero aún se pueden bloquear los sitios que los publican. |
| Enlace roto | El archivo sobrevive mientras el host lo haga. | El texto sobrevive, pero es inútil si ningún par aún posee los metadatos. |
| Valor de archivo | Alto: conserva metadatos completos incluso cuando el enjambre está muerto. | Bajo: depende de un enjambre en vivo para recuperar los metadatos. |
| Sitios de indexación y búsqueda | Debe almacenar un archivo por torrent (más espacio de almacenamiento) | Almacena solo un trozo corto de cuerda (más barato y más fácil de duplicar). |
| Comodidad entre dispositivos | Necesita una transferencia de archivos | Fácil: copia y pega, o escanea un código QR. |
| Comportamiento del navegador | Descarga un archivo y luego lo abre en un cliente. | Activa una solicitud del controlador de protocolo (requiere un cliente registrado). |
5. Comportamiento y rendimiento de la red
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| descubrimiento entre pares | Los rastreadores que aparecen en el archivo, además de DHT, PEX y LSD (a menos que sean privados). | DHT, PEX y LSD, además de cualquier rastreador tr en el enlace |
| Funciona sin ningún rastreador. | Solo si se permite la DHT | Sí, con DHT (este es su modo habitual). |
| Dependencia de DHT | Opcional | A menudo esencial para los metadatos y los pares. |
| Semillas web (fuentes HTTP) | campos url-list / httpsseeds (BEP 19) | ws= parámetro, una extensión dependiente del cliente no definida en BEP 9 |
| Velocidad de descarga una vez en ejecución | Idéntico | |
| Comportamiento con torrentes muertos o poco frecuentes | Comienza y espera a sus pares. | Puede detenerse al "recuperar metadatos" |
| rastreadores privados | Totalmente compatible (bandera privada, clave de acceso en la URL de anuncio) | Generalmente inutilizable. Los torrents privados desactivan DHT/PEX y la clave de acceso del rastreador no se expone en un enlace compartible. |
6. Seguridad
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Fuente de riesgo de malware | El contenido descargado, no el formato. | El contenido descargado, no el formato. |
| Riesgo del analizador o del manejador | El código Bencode mal formado puede provocar errores en un cliente mal programado (poco frecuente). | Los parámetros dn o URI maliciosos pueden provocar errores de inyección o visualización en clientes o manejadores mal escritos (poco frecuente). |
| Posibilidad de inspeccionar antes de descargar. | Alto: puedes ver primero la lista de archivos, extensiones y tamaños. | Bajo hasta que lleguen los metadatos; la mayoría de los clientes permiten revisar la lista de archivos antes de descargarlos. |
| Archivos ejecutables disfrazados | Detectable en la lista de archivos (.exe, .scr, .lnk, etc.) | Igual, pero solo después de que se hayan obtenido los metadatos. |
| Riesgo de phishing y publicidad | Los sitios de torrents suelen estar repletos de anuncios. | Lo mismo, además de clics accidentales en botones magnéticos similares. |
| Fuerza de hash | SHA-1 para v1 (en teoría, débil ante colisiones, difícil de explotar para torrents); SHA-256 para v2 | El mismo hash que el torrent al que apunta. |
| Manipulación durante el transporte | Detectado mediante hashes de piezas | Detectado a través del hash de información, aunque un enlace intercambiado apunta a un contenido completamente diferente. |
7. Privacidad y anonimato
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Tu IP es visible para otros usuarios. | Sí | |
| Tu IP es visible para los rastreadores. | Sí (rastreadores integrados) | Sí, si se incluyen los rastreadores TR. |
| exposición a DHT | Posible | Casi seguro; tus consultas van al DHT público. |
| Diferencia de anonimato | Ninguno significativo | |
| Metadatos que revelan al que comparte | Creado por, comentario y fecha de creación pueden revelar detalles | Nada más allá de lo que contiene el texto del enlace. |
| Medidas de mitigación | VPN o apoderado, del lado del cliente cifradorastreadores privados | |
8. Riesgos y limitaciones
| Riesgo | archivo .torrent | Enlace magnético |
|---|---|---|
| Puestos sin pares | Espera a sus compañeros | Es posible que nunca se obtengan los metadatos. |
| Contenido falso o mal etiquetado | Posible | |
| Exposición legal | Depende del contenido y la jurisdicción. Alojar el archivo puede implicar una mayor exposición para los operadores del sitio. | Depende del contenido y la jurisdicción. Compartir enlaces a veces se trata de manera diferente a alojar archivos, pero esto varía y no es un puerto seguro. |
| exposición de la privacidad | Visibilidad del rastreador y de los pares | DHT y visibilidad entre pares |
| Muerte del rastreador | Reduce el descubrimiento, pero la DHT aún puede funcionar. | No hay problema si el enlace depende del DHT. |
| Durabilidad a largo plazo | Mejor | Peor |
| Errores tipográficos y truncamientos | Se ha detectado un archivo dañado. | Un error tipográfico en el hash no lleva a ninguna parte, y un enlace truncado se rompe silenciosamente. |
9. Compatibilidad y usabilidad
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Soporte al cliente | Universal | Universal en clientes modernos (requiere BEP 9) |
| Seedboxes y servicios web | Con apoyo universal | Mayormente compatible, aunque algunos servicios más antiguos solo aceptan archivos. |
| Compatibilidad con dispositivos móviles | Moderado (el manejo de los archivos descargados es engorroso) | Alto |
| Automatización (RSSscripts, API) | Directo | También sencillo y más fácil de almacenar. |
| legibilidad humana | No se puede leer sin una herramienta. | El hash es opaco, pero la estructura es legible. |
10. Cómo crear archivos .torrent y enlaces magnéticos
Los elementos marcados con una daga son fruto de mi propio razonamiento o conocimiento general, no confirmados en ninguna fuente.
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Entrada inicial | Tus archivos o carpeta reales, más una herramienta de creación (por ejemplo, mktorrent o la función "crear torrent" de un cliente). | Un hash de información existente. En v1, ese es el SHA-1 del diccionario de información codificado con ben, por lo que un enlace magnet no puede existir antes de que existan los metadatos .torrent. |
| Orden de los pasos | 1) Elige la longitud de la pieza. 2) Calcula el hash de cada pieza. 3) Construye el diccionario de información. 4) Agrega campos externos como rastreadores. 5) Codifica con Bencode y guarda. | 1) Obtén el torrent. 2) Toma su info-hash. 3) Escribe la URI con xt. 4) Opcionalmente, agrega dn, tr y x.pe. |
| Longitud de la pieza | Tú lo eliges. Casi siempre es una potencia de dos, generalmente 256 KiB. mktorrent tiene por defecto 2^18 bytes y lo establece con -l | Ninguno; se hereda del torrente |
| Trabajo de hash | Cada byte se somete a un hash: fragmentos SHA-1 para la versión 1, árboles Merkle SHA-256 por archivo para la versión 2. El tiempo aumenta con el tamaño de los datos (dagger), y mktorrent puede usar varios hilos. | Insignificante: nada más allá del hash existente |
| Rastreadores | anunciar o lista de anuncios. La lista se encuentra fuera de la sección de información; si está presente, los clientes compatibles ignoran el anuncio y los niveles se prueban en orden, con las URL dentro de un nivel mezcladas. | tr= parámetros en la URI. Si no se proporciona ninguno, los clientes deben usar DHT. |
| Bandera privada | Se configura estableciendo private=1 en el diccionario de información. Los clientes compatibles se anuncian entonces solo al rastreador privado y se conectan solo a los pares que este devuelve. Dado que es información interna, afecta al hash de información (daga). | No hay ningún campo para ello en el enlace. La bandera reside en los metadatos, que el cliente solo ve después de obtenerlos (daga). |
| Semillas web | lista de URL, según BEP 19. mktorrent la expone como -w. El servidor HTTP/FTP actúa como una semilla permanentemente sin restricciones | ws= no forma parte de la lista de parámetros de BEP 9. Trátelo como una extensión dependiente del cliente. |
| Campos descriptivos opcionales | El comentario y la fecha de creación son opcionales. mktorrent ofrece la opción -c para añadir un comentario y -d para omitir la fecha. | Solo dn (nombre para mostrar). Es una etiqueta y no está verificada. |
| Etiqueta de origen | La opción -s de mktorrent incrusta una cadena de origen en el info-hash, por lo que los mismos archivos con una etiqueta diferente obtienen un hash diferente y un swarm separado. | No aplicable |
| ¿Qué cambia la identidad? | Información interna: nombre, longitud de la pieza, bandera privada, etiqueta de origen, lista de archivos (daga) | Cambiar xt apunta a un torrent diferente. Cambiar dn, tr o x.pe no lo hace. |
| Elección de versión de hash | v1 (SHA-1), v2 (SHA-256) o híbrido, elegido en el momento de la creación. | El enlace debe contener btih, btmh o ambos para un híbrido (BEP 9 permite ambos temas en un solo magnet si describen el mismo torrent híbrido). |
| Firma | BEP 35 permite firmas RSA incrustadas en el archivo, opcionalmente con un certificado X.509, y varias firmas por torrent. Rara vez se usa (dagger). | BEP 9 no define ningún campo de firma, por lo que no hay nada que firmar. |
| Producción | Un archivo binario de KB a MB, que usted debe alojar o enviar. | Una línea de texto de unos pocos cientos de bytes |
| Hacerlo utilizable | Sube el archivo y ejecuta un cliente con los datos originales para que puedas inicializarlo. | Publica la línea y continúa compartiendo. El enlace no sirve de nada si ningún otro usuario tiene los datos y metadatos. |
| Errores típicos | Tamaño de pieza incorrecto para el tamaño del contenido (daga); olvidar la bandera privada antes de publicar, ya que cambiarla después implica un nuevo hash (daga); agregar el rastreador incorrecto | Error tipográfico o truncamiento en el hash, por lo que el enlace no apunta a ninguna parte (dagger); prefijo incorrecto (btih vs btmh); caracteres especiales sin escape en dn (dagger) |
11. Usando cada uno
Los elementos marcados con una daga son fruto de mi propio razonamiento o conocimiento general, no confirmados en ninguna fuente.
| Aspecto | archivo .torrent | Enlace magnético |
|---|---|---|
| Cómo lo abres | Haga doble clic en la asociación de archivos, arrástrelo a un cliente o utilice "Agregar archivo torrent". | Haz clic en un imán: enlace (requiere un gestor registrado), pégalo en un cliente o escanea un código QR (daga). |
| Lo primero que hace el cliente | Analiza la metainformación codificada con ben | Analiza la URI y extrae el hash de información. |
| De dónde provienen los metadatos | Ya está en el archivo | Los pares envían el diccionario de información (solo esa parte del .torrent) en bloques de 16 KiB a través de la extensión BEP 9, y el cliente lo verifica contra el hash. |
| Encontrar compañeros | Rastreadores del archivo, además de DHT/PEX/LSD a menos que el torrent sea privado. Para torrents privados, no se deben usar DHT ni PEX. | Rastreadores en el enlace; si no hay ninguno, el DHT |
| Retardo de inicio | Ninguno | Espera hasta que un par con los metadatos responda, por lo que puede quedarse bloqueado indefinidamente. |
| Seleccionar archivos antes de la descarga | Inmediatamente | Una vez que llegan los metadatos. Algunos clientes pueden obtener solo los metadatos, para previsualizar la lista de archivos antes de descargarlos. |
| Inspeccionar antes de comprometerse | Inspección completa con cualquier herramienta de análisis sintáctico, sin conexión. | No es posible hasta que se obtengan los metadatos. |
| Convertir entre ellos | Calcula el hash de información y escribe un enlace magnético (daga). | Los metadatos obtenidos se pueden exportar y almacenar en caché como un torrent, por lo que el mismo enlace magnético nunca necesita una segunda descarga de metadatos. |
| Uso de rastreadores privados | Funciona, ya que el archivo contiene la URL del rastreador y los clientes deben limitarse a ella (BEP 27). | Probablemente poco práctico: el enlace no tiene bandera y una URL de seguimiento puede contener credenciales personales (daga). BEP 27 no trata sobre imanes. |
| Edición | Agregue o elimine rastreadores sin cambiar el hash, ya que están fuera de la sección de información. Editar la información crea un nuevo torrent. | Edita el texto libremente; al modificar xt cambia qué torrent es |
| Verificación de autenticidad | Verifique una firma BEP 35 con un certificado de confianza. Una biblioteca indica que su verificación no valida el certificado en sí. De lo contrario, inspeccione la lista de archivos. | Compare el hash de información con uno de una fuente confiable; no hay nada más disponible. |
| Actualizaciones automáticas | BEP 39 permite que un creador coloque una URL de actualización en el diccionario de información, y los clientes descargan torrents más nuevos automáticamente solo si están firmados por el originador. | Ninguno |
| Compartiendo adelante | Enviar o alojar el archivo | Copia y pega la línea |
| Cuando falla | Rastreador inactivo o sin pares: el cliente espera. Se rechaza un archivo corrupto. | Error tipográfico en el hash o no hay un par alcanzable: atascado en "recuperando metadatos" |
| Rescate de semillas de la web | Un archivo .torrent con una semilla web sigue funcionando sin pares. Los enlaces magnet no tienen equivalente, porque ni BEP 9 ni los BEP de siembra HTTP proporcionan una forma de obtener metadatos de las semillas HTTP. | |
| Después de la descarga | Sigue compartiendo desde los mismos archivos. | |
Resumen
Los archivos torrent (.torrent) son ideales para archivar, usar rastreadores privados, revisar primero la lista de archivos y acceder a metadatos sin conexión, mientras que los enlaces magnéticos destacan por su rápida compartición, códigos QR, distribución independiente del rastreador y alojamiento mínimo.
Ninguno de los dos formatos es intrínsecamente más seguro. Ambos verifican la integridad de los datos criptográficamente, pero ninguno autentica quién publicó el contenido ni cuál es realmente. El verdadero riesgo para la seguridad y los aspectos legales reside en el contenido y su origen, así que revise la lista de archivos en busca de extensiones sospechosas y tenga cuidado con la procedencia del enlace.
Preguntas frecuentes
¿BitTorrent es un estándar IETF o ISO, y qué tan formal es el estatus de los archivos .torrent y los enlaces magnet?
No. El protocolo se especifica mediante las Propuestas de Mejora de BitTorrent (BEP), un proceso basado en las PEP de Python. La BEP 3 define el formato de metainformación y la BEP 52 define la versión 2. La BEP 9, que abarca el intercambio de metadatos y el formato magnet de BitTorrent, tiene el estado «Aceptado», no «Final». El esquema magnet: en sí mismo es solo un registro provisional de la IANA, creado por el Proyecto Magnet-URI. En la práctica, la interoperabilidad la definen las principales bibliotecas cliente, así que conviene probar con varias implementaciones.
¿El hash de información vincula criptográficamente un torrent con su contenido?
De forma transitiva, sí. El hash de información v1 es el SHA-1 del diccionario de información codificado, y ese diccionario contiene el hash SHA-1 de cada pieza, por lo que el hash se incorpora a los datos. La salvedad es la menor resistencia a las colisiones de SHA-1: existen colisiones prácticas, por lo que un editor que crea ambas variantes de un torrent podría generar dos cargas útiles con un solo hash. Los ataques de segunda preimagen contra un torrent existente siguen siendo inviables. La versión 2 utiliza SHA-256 y elimina este problema.
¿Qué ediciones cambian la identidad de un torrent y cuáles no?
Todo lo que se encuentra dentro del diccionario de información modifica el hash de información: nombre, lista de archivos, longitud de la pieza, la bandera privada y una etiqueta de origen como la opción -s de mktorrent. Los campos fuera de él, como announce y announce-list (BEP 12), se pueden editar libremente sin crear un nuevo torrent. En un enlace magnet, dn, tr y x.pe nunca afectan la identidad; solo xt lo hace. Modificar el diccionario de información crea una bifurcación silenciosa del enjambre, por lo que debe tratarse como publicar un nuevo torrent.
¿Cómo autentica un cliente los metadatos recibidos a través de un enlace magnet?
Los nodos envían el diccionario de información en bloques de 16 KiB mediante la extensión ut_metadata de BEP 9. El cliente aplica un hash al resultado resultante y lo compara con el hash de información del enlace. Los metadatos falsificados se rechazan a menos que el atacante pueda descifrar el hash. Esto demuestra la integridad con respecto al enlace, no la veracidad. El valor dn es una etiqueta no verificada, y el hash no indica quién publicó el contenido ni qué contiene realmente.
¿Cuáles son las diferencias prácticas entre los torrents v1, v2 e híbridos?
v1 utiliza una lista plana de hashes de piezas SHA-1 en el diccionario de información. v2 (BEP 52) utiliza SHA-256 con un árbol Merkle por archivo y un árbol de archivos jerárquico. Las capas de piezas se encuentran fuera del diccionario de información, y las implementaciones deben compararlas con los campos raíz de piezas dentro del mismo. Un torrent híbrido contiene ambas estructuras y, por lo tanto, tiene dos hashes de información, y un enlace magnet puede contener temas bth y btmh. Verifique que su cliente y herramientas sean compatibles con v2 antes de publicar torrents que solo admitan v2.
¿Puede un enlace magnet iniciar una descarga cuando no hay pares pero existe una semilla web HTTP?
No. BEP 9 solo recupera metadatos de pares, y ni BEP 9 ni los BEP de siembra HTTP (17, 19) definen una forma de obtener metadatos de una semilla HTTP. Un archivo .torrent con una semilla web sigue funcionando incluso sin pares, porque los metadatos ya están en el archivo. Si dependes de semillas web para la disponibilidad, distribuye el archivo .torrent, no solo un enlace magnet.
¿Qué revela cada formato sobre mi privacidad y mi identidad en la red?
Ambos métodos exponen tu dirección IP a otros usuarios y a cualquier rastreador que hayas anunciado. Los enlaces magnet suelen depender de la DHT pública, que añade otra ruta de búsqueda donde aparecen tu IP y el hash de información. El cifrado de protocolo ofusca el tráfico, pero no te anonimiza. Los torrents privados (BEP 27) requieren que los clientes utilicen únicamente el rastreador privado, por lo que no se utilizan DHT ni PEX. Para garantizar el anonimato, utiliza un modelo de amenazas con la mitigación adecuada a nivel de red, no un formato específico.
¿Cómo puedo verificar la autenticidad, y no solo la integridad, de los datos obtenidos a través de torrent?
La verificación de fragmentos solo demuestra que los datos coinciden con el torrent. Para garantizar la autenticidad, obtenga una suma de comprobación o firma (por ejemplo, un manifiesto SHA-256 firmado) a través de un canal independiente de confianza y verifique los archivos finales con ella. BEP 35 define firmas RSA integradas en archivos .torrent, con certificados X.509 opcionales y múltiples firmantes, pero rara vez se implementa, y una biblioteca que lo implementa señala que su verificación no valida el certificado en sí. Los enlaces magnet no tienen ningún mecanismo de firma.
¿Cómo debo elegir la longitud de un archivo torrent al crearlo?
Se trata de una compensación entre el tamaño de los metadatos y la granularidad de la transferencia. BEP 3 establece que la longitud de los fragmentos es casi siempre una potencia de dos, generalmente 256 KiB, que también es el valor predeterminado de mktorrent. En la versión 1, una carga útil de 100 GiB a 256 KiB tiene 409.600 fragmentos, por lo que la cadena de fragmentos por sí sola ocupa unos 8 MB. Los clientes magnet deben descargar todo ese diccionario en aproximadamente 500 bloques antes de comenzar, por lo que los metadatos de gran tamaño ralentizan el inicio de los magnet. Los fragmentos más grandes reducen el tamaño de los metadatos, pero hacen que la reparación después de un fragmento fallido sea menos precisa.
¿Por qué dos torrentes de datos idénticos terminan en enjambres separados, y cómo puedo evitarlo?
Porque el info-hash abarca todo el diccionario de información. Diferentes nombres, orden de archivos, longitudes de fragmentos, indicadores privados o etiquetas de origen producen distintos hashes incluso para cargas útiles idénticas en bytes. Para mantener un único swarm, estandarice la longitud de los fragmentos, el nombre, el orden de los archivos y los indicadores en su proceso de lanzamiento, y publique el info-hash junto con el artefacto. Las etiquetas de origen son una forma intencionada de separar los swarms, y la opción -s de mktorrent modifica deliberadamente el hash.
¿Cuáles son las principales preocupaciones de seguridad al escribir un cliente o un analizador sintáctico para estos formatos?
Trate todas las entradas como no confiables. Valide estrictamente el código Bencode, limite el tamaño de los metadatos (un cliente de código abierto impone un límite de 32 MB) y elimine las rutas de archivo de los metadatos para evitar el acceso no autorizado a directorios. Filtre las direcciones privadas y de bucle invertido devueltas por los rastreadores y la DHT para limitar el abuso de tipo SSRF y verifique que las URL de los rastreadores sean aceptables antes de conectarse. Trate los nombres de dominio como texto no confiable y verifique el hash de cada fragmento antes de escribirlo en el almacenamiento final.
¿Cómo calculo correctamente un info-hash a partir de un archivo .torrent?
Localiza el intervalo exacto de bytes del valor de información tal como aparece en el archivo y calcula su hash: SHA-1 para v1 o SHA-256 para v2. BEP 3 enfatiza que el hash se aplica sobre la codificación presente en el archivo. Decodificar y volver a codificar el diccionario solo es seguro si el decodificador validó completamente la entrada; un decodificador permisivo puede normalizar los datos silenciosamente y generar un hash diferente. Para torrents híbridos, calcula ambos hashes a partir del mismo intervalo.
¿Puedo usar un enlace magnet para un torrent de un rastreador privado?
A menudo, esto no es práctico. BEP 27 exige que los clientes anuncien su conexión únicamente al rastreador privado y que se conecten solo a los pares que este devuelva. Un enlace magnet simple no contiene ninguna bandera privada, ya que esta reside en los metadatos, y puede que no incluya una URL de rastreador utilizable. Si se incluye una URL de rastreador con credenciales, trate el enlace como un secreto. Esta es mi conclusión a partir de la especificación, ya que BEP 27 no aborda los enlaces magnet directamente, así que pruébelo con las reglas de su rastreador.
Para distribuir software, conjuntos de datos o archivos en un flujo de trabajo, ¿debo publicar un enlace .torrent o un enlace magnet?
Publique ambos archivos, con el archivo .torrent como artefacto canónico. Esto conserva los metadatos completos, permite a los usuarios consultar la lista de archivos sin conexión y admite semillas web (BEP 19) para garantizar la disponibilidad. Para mayor comodidad, derive el enlace magnet del mismo hash de información y publique el hash de información junto con una suma de verificación firmada en un canal de confianza. Esto proporciona durabilidad de archivo y facilita el intercambio sin que la recuperación de metadatos dependa de otros usuarios.
¿Qué determina cuánto tiempo permanece disponible un archivo torrent y cómo puedo mejorarlo?
La recuperabilidad requiere al menos un nodo accesible que contenga los datos, y en el caso de los enlaces magnet, uno que también contenga los metadatos. Para mejorarla, se recomienda mantener los seeders activos, añadir varios rastreadores en niveles (BEP 12) como respaldo, añadir semillas web HTTP y mantener el archivo .torrent archivado o exportable desde clientes que almacenen en caché los metadatos obtenidos. Un enlace magnet por sí solo no conserva nada, por lo que un enjambre inactivo lo vuelve inútil.
Lista ampliada de lecturas y temas relacionados
- Bencoding: el formato de serialización utilizado por los archivos .torrent, con claves de diccionario ordenadas
- Hash de información: Resumen SHA-1 (v1) o SHA-256 (v2) del diccionario de información codificado, la identidad del torrent.
- Almacenamiento direccionable por contenido: identificar datos por su hash en lugar de por su ubicación
- Árboles Merkle: Árboles hash por archivo en BitTorrent v2 (BEP 52) para verificación a nivel de fragmento
- Torrents híbridos: torrents individuales que contienen estructuras v1 y v2 y dos hashes de información.
- Longitud y número de capas de las piezas: La disyuntiva entre el tamaño de los metadatos y la granularidad de la verificación.
- Resistencia a colisiones SHA-1: Por qué el hash v1 es teóricamente más débil y v2 pasa a SHA-256.
- Protocolo de extensión (BEP 10): el mecanismo de enlace que habilita ut_metadata, PEX y otras extensiones
- Intercambio de metadatos (BEP 9, ut_metadata): Obteniendo el diccionario de información de pares en bloques de 16 KiB.
- Esquema URI Magnet: un esquema de identificador basado en hash, independiente del proyecto, con un registro provisional de IANA.
- MAGMA (manifiesto magnético): el concepto de tema manifiesto de los orígenes de red múltiple del esquema magnético
- Selección de archivos magnéticos (BEP 53): elegir archivos específicos dentro de un torrent desde el propio enlace
- Metadatos del sistema multitracker (BEP 12): Niveles de lista de anuncios con reordenamiento y conmutación por error
- UDP Protocolo de seguimiento (BEP 15): Anuncio de rastreador ligero a través de UDP
- Listas de pares compactas (BEP 23): la codificación binaria compacta de pares en las respuestas del rastreador
- Extensión de rastreador IPv6 (BEP 7): peers6 anuncia compatibilidad con IPv6
- Informes de IP externa del rastreador (BEP 24): rastreadores que informan a los clientes sobre su dirección observada
- DHT principal (BEP 5): la tabla hash distribuida basada en Kademlia para el descubrimiento de pares sin rastreador
- Extensión de seguridad DHT (BEP 42): restringir los ID de nodo para resistir ataques Sybil y de tabla de enrutamiento
- Indexación DHT put/get e infohash (BEP 44, BEP 51): almacenar datos y muestrear info-hashes en la DHT
- Intercambio entre pares, PEX (BEP 11): miembros del enjambre que comparten listas de pares directamente
- Descubrimiento de servicios locales (BEP 14): encontrar pares en el mismo segmento de red
- Extensión rápida (BEP 6): atajos de protocolo como tener todo, no tener nada y rechazar
- uTP (BEP 29): un transporte basado en UDP con control de congestión basado en retardo
- Extensión de perforación (BEP 55): El recorrido NAT se coordina mediante la retransmisión entre pares.
- Cifrado de flujo de mensajes (MSE/PE): Ofuscación de protocolos, no anonimato.
- Torrents privados (BEP 27): la bandera privada que restringe el descubrimiento de pares al rastreador
- Siembra de la red (BEP 17, BEP 19): Servidores HTTP o FTP que actúan como semillas permanentes
- Archivos de relleno (BEP 47): Alineación de archivos con los límites de las piezas para la deduplicación y la compatibilidad híbrida.
- Sugerencias de datos locales (BEP 38): reutilizar datos de torrents relacionados para evitar volver a descargarlos
- Firma de torrents (BEP 35): Firmas RSA integradas con certificados X.509 opcionales.
- Fuentes de actualización de torrents (BEP 39): URL de actualización para torrents sucesores automáticos firmados
- Proceso de verificación de piezas: Verificación de hash antes de la confirmación y recuperación de partes fallidas
- Refuerzo del analizador sintáctico y del cliente: código Bencode estricto validaciónlímites de tamaño, saneamiento de rutas, filtrado SSRF
- WebTorrent y WebRTC: pares basados en navegador que utilizan rastreadores ws/wss e ICE o TURN
- Cajas de semillas y siembra a largo plazo: infraestructura para la disponibilidad y la persistencia del archivo
- Proceso y gobernanza del BEP: cómo se proponen, indexan y promueven las especificaciones desde Aceptadas hasta Finalizadas
- Sistemas alternativos de direccionamiento de contenido: Identificadores de contenido al estilo IPFS como modelo comparable
- Procedencia versus integridad: ¿Por qué los hashes verifican los datos pero nunca autentican al editor?
Enlaces externos en Torrent
(Pase el cursor sobre el enlace para ver nuestra descripción del contenido)
