A .torrent file and a magnete link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- Un file .torrent è un file di "metadati". Il suo dizionario info contiene la lunghezza del pezzo, il nome e la lunghezza del file (o un elenco di file) e, nella versione 1, un elenco concatenato di hash SHA-1 a 20 byte, uno per pezzo. L'hash info è l'SHA-1 a 20 byte del valore info codificato in ben, calcolato sulla forma codificata esattamente come appare nel file .torrent. Gli URL dei tracker si trovano al di fuori di quel dizionario, quindi possono essere modificati senza alterare l'identità del torrent. BitTorrent v2 (BEP 52) cambia l'hashing: utilizza SHA-256 con un albero Merkle per file e un albero di file gerarchico. I "livelli dei pezzi" per file si trovano al di fuori del dizionario info e le implementazioni dovere controllali rispetto ai campi radice dei pezzi al suo interno. bep 0003 +2
- Un link magnet non contiene metadati, ma solo l'identità. Il suo formato è magnet:?xt=urn:btih: per la versione 1 o xt=urn:btmh: per la versione 2, con parametri opzionali nome visualizzato (dn), tracker (tr) e indirizzo peer (x.pe). Un torrent ibrido può contenere sia argomenti btih che btmh in un unico link. Per iniziare, il client recupera i metadati dagli altri peer utilizzando l'estensione BEP 9. Questa estensione trasferisce solo la parte info-dictionary del file .torrent, in blocchi da 16 KiB. Il client quindi la confronta con l'hash presente nel link. Se il link non specifica alcun tracker, il client deve utilizzare il DHT per trovare i peer. bep 0009 +2
Quindi i due formati puntano allo stesso swarm e, una volta avviato il download, forniscono lo stesso risultato. La differenza risiede nella provenienza dei metadati:
Un file .torrent è un artefatto statico: l'elenco dei file è noto immediatamente, i metadati sopravvivono anche in caso di interruzione del servizio e il file deve essere ospitato da qualche parte.
Un link magnet è una breve stringa che può essere incollata ovunque, ma funziona solo finché almeno un peer raggiungibile possiede ancora i metadati. Nessuno dei due formati autentica l'editore o conferma che il contenuto corrisponda all'etichetta. L'hash dimostra solo che i dati corrispondono all'hash.
Mancia: Su richiesta popolare, questo post funge da supporto per tutti i nostri post su torrent e P2P per l'ingegneria.
Storia e contesto
Il formato .torrent deriva dal design originale di BitTorrent. Bram Cohen ha ideato il protocollo nell'aprile del 2001 e ha rilasciato la prima versione il 2 luglio 2001. Insieme ad Ashwin Navin, ha fondato BitTorrent, Inc. (in seguito Rainberry, Inc.) nel 2004. Cohen è anche l'autore di BEP 3, la specifica principale che definisce il file metainfo e l'info-hash. L'ulteriore sviluppo è coordinato attraverso il processo BitTorrent Enhancement Proposal (BEP), modellato sulle PEP di Python, e Cohen desiderava che il client principale rimanesse open source.
La specifica BEP 3 è la cosa più vicina all'autorità formale per la formato fileIl formato v2 è arrivato molto più tardi: BitTorrent, Inc. ha rilasciato la specifica v2 il 15 maggio 2017. I link magnet hanno un'origine diversa. Lo schema magnet: non è stato inventato per BitTorrent. È stato progettato come un metodo indipendente dal progetto per identificare i file tramite hash del contenuto su diverse reti P2P. L'IANA lo elenca solo come schema provvisorio, registrato nel 2012 con il Magnet-URI Project come suo creatore. Fonti secondarie ne datano l'introduzione al 2002, ma non ho trovato fonti primarie che confermino tale data. L'utilizzo dei link magnet da parte di BitTorrent si basa su BEP 9, scritto da Greg Hazel e Arvid Norberg (Norberg è anche l'autore originale di libtorrent). Il BEP 9 è ancora solo "Accettato", non definitivo, e ha acquisito il parametro di indirizzo peer x.pe nel 2016. Tale BEP definisce sia il protocollo di scambio di metadati che il formato del magnet link di BitTorrent, ma le note di un implementatore descrivono gli URI del magnet link come una convenzione di fatto, non come un BEP numerato.
In pratica, entrambi i formati si basano sul processo BEP e su ciò che i principali clienti implementano, non su un formato formale standard corpo.
1. Fondamenti
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Che cos'è | Un piccolo file binario (dizionario codificato in ben) | Un URI di testo (magnet:?xt=urn:btih:…) |
| Contiene il contenuto? | No, solo metadati | No, solo un identificatore |
| Contenuti principali | URL(i) del tracker, nomi e dimensioni dei file, lunghezza del brano, hash di ogni brano, commento facoltativo, autore e data | Info-hash (xt), nome visualizzato opzionale (dn), tracker (tr), indirizzi peer (x.pe); web seed (ws) solo come estensione dipendente dal client, non definito in BEP 9 |
| Dimensioni tipiche | Da pochi KB a diversi MB (la quantità aumenta con le dimensioni del contenuto) | Circa 100-500 byte |
| Identificativo utilizzato | Hash informativo SHA-1 (v1), SHA-256 (v2) o entrambi (ibrido) | Lo stesso hash informativo: urna:btih (v1) o urn:btmh (v2) |
| Specifiche | BEP 3 (v1), BEP 52 (v2) | BEP 9 (scambio di metadati e formato URI magnet) |
| Gestore del protocollo | Aperto tramite associazione di file (.torrent) | Aperto dal magnete del sistema operativo o del browser: gestore URI |
2. Metadati e informazioni sui file
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Elenco dei file visibile prima dell'avvio del download | Sì, subito | No, solo dopo che i metadati sono stati recuperati dai peer |
| Fonte dei metadati | Incorporato nel file | Scaricato dai peer (DHT, PEX, tracker) tramite ut_metadata |
| Integrità dei metadati | Verificato tramite hashing | Verificato rispetto all'info-hash nel link, quindi i metadati manomessi vengono rifiutati |
| Ritardo di avvio | Nessuno | Da secondi a minuti (o mai, se nessun altro utente possiede i metadati) |
| Nome da visualizzare | Memorizzato nel file (nome) | dn è facoltativo e non verificato; è solo un'etichetta |
| Hash dei pezzi | Incluso | Ottenuto successivamente con i metadati |
| Modificabile | È possibile modificare i tracker senza cambiare l'hash. La modifica del dizionario info cambia l'info-hash, creando un torrent diverso. | Facile da modificare come testo (aggiungere o rimuovere tracker). L'info-hash non può essere modificato senza puntare a un contenuto diverso. |
3. Autore, provenienza e autenticità
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Informazioni sull'autore | Campi opzionali: creato da (client e versione), data di creazione, commento | Nessuno; non esiste un campo autore standard |
| Fuga di metadati sul creatore | Possibile (versione del client, data e ora, a volte commenti o URL) | Minimo; il link contiene solo ciò che chi lo ha condiviso ha incluso |
| Firma digitale | Esiste una proroga per la firma (BEP 35), ma viene usata raramente. | Nessuno |
| Prova che il contenuto corrisponde a quanto dichiarato sull'etichetta. | Nessuno, e il nome può essere falsificato | Nessuno, e dn può essere falsificato |
| Prova che il contenuto corrisponde all'hash | Sì, ogni pezzo è verificato tramite hash. | Sì, ogni elemento viene verificato tramite hash dopo i metadati verifica |
| Modello di fiducia | Ti fidi di chi ha fornito il file, quindi verifichi i dati confrontandoli con gli hash. | Ti fidi di chi ha fornito il link, quindi verifica allo stesso modo |
| Rischio di spoofing | I torrent falsi con lo stesso titolo sono comuni | Lo stesso vale per il link, che ha ancora meno contesto (non c'è un elenco di file da esaminare prima). |
4. Hosting, distribuzione e disponibilità
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Necessita di hosting | Sì, un server web, un sito indicizzato o una condivisione di file. | No; è solo testo e può essere incollato ovunque |
| Metodi di condivisione | Download, allegato e-mail, trasferimento file (gli allegati a volte vengono bloccati) | Chat, corpo dell'email, codice QR, messaggio sul forum, app per le note |
| Esposizione della rimozione | I file ospitati possono essere rimossi o bloccati | Più difficile da rimuovere (solo testo), ma i siti che li pubblicano possono comunque essere bloccati. |
| Marciume del collegamento | Il file sopravvive finché esiste l'host | Il testo sopravvive, ma è inutile se nessun altro possiede ancora i metadati |
| Valore di archiviazione | Alto: conserva i metadati completi anche quando lo sciame è morto | Basso: dipende da uno sciame attivo per recuperare i metadati |
| siti di indicizzazione e ricerca | È necessario memorizzare un file per ogni torrent (più spazio di archiviazione) | Conserva solo una corda corta (più economica e più facile da specchiare) |
| Comodità multi-dispositivo | È necessario trasferire un file | Facile: copia e incolla oppure scansiona un codice QR |
| Comportamento del browser | Scarica un file, quindi lo apre in un client | Attiva una richiesta di gestione del protocollo (richiede un client registrato) |
5. Comportamento e prestazioni della rete
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Scoperta tra pari | Nel file sono elencati i tracker, oltre a DHT, PEX e LSD (a meno che non siano privati). | DHT, PEX e LSD, oltre a qualsiasi tracker tr nel link |
| Funziona senza alcun tracker | Solo se il DHT è consentito | Sì, con DHT (questa è la sua modalità normale) |
| Dipendenza dal DHT | Opzionale | Spesso essenziale per i metadati e i peer |
| Semi web (sorgenti HTTP) | campi url-list / httpseeds (BEP 19) | ws= parametro, un'estensione dipendente dal client non definita in BEP 9 |
| Velocità di download una volta avviato | Identico | |
| Comportamento con torrent inattivi o rari | Si avvia e attende i colleghi | Potrebbe bloccarsi durante il recupero dei metadati. |
| Tracker privati | Pienamente supportato (flag privato, password nell'URL di annuncio) | Generalmente inutilizzabile. I torrent privati disabilitano DHT/PEX e la password del tracker non è disponibile in un link condivisibile. |
6. Sicurezza
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Fonte di rischio malware | Il contenuto scaricato, non il formato | Il contenuto scaricato, non il formato |
| rischio del parser o del gestore | Un bencode malformato può innescare bug in un client scritto male (raro). | Parametri dn o URI dannosi possono causare bug di iniezione o di visualizzazione in client o gestori scritti male (raro) |
| Possibilità di ispezionare prima del download | Alto: puoi visualizzare prima l'elenco dei file, le estensioni e le dimensioni | Basso fino all'arrivo dei metadati; la maggior parte dei client consente quindi di rivedere l'elenco dei file prima del download. |
| File eseguibili camuffati | Rilevabile nell'elenco dei file (.exe, .scr, .lnk e così via) | Lo stesso vale, ma solo dopo che i metadati sono stati recuperati. |
| Rischi di phishing e pubblicità | I siti torrent sono spesso pieni di pubblicità | Stessa cosa, più clic accidentali su pulsanti magnetici simili |
| Potenza di hash | SHA-1 per v1 (in teoria debole alle collisioni, difficile da sfruttare per i torrent); SHA-256 per v2 | Lo stesso hash del torrent a cui punta |
| Manomissione durante il trasporto | Rilevato tramite hash dei pezzi | Rilevato tramite l'info-hash, sebbene un link invertito punti a contenuti completamente diversi. |
7. Privacy e anonimato
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Il tuo indirizzo IP è visibile ai peer | SÌ | |
| Il tuo indirizzo IP è visibile ai tracker | Sì (tracker integrati) | Sì, se sono inclusi i tracker tr |
| Esposizione al DHT | Possibile | Quasi certo; le tue ricerche vanno al DHT pubblico |
| differenza di anonimato | Nessuno significativo | |
| Metadati che rivelano chi condivide | creato da, commento e data di creazione possono rivelare dettagli | Niente di più di quanto contenuto nel testo del link. |
| Misure di mitigazione | VPN o procuratorelato client crittografiatracker privati | |
8. Rischi e limitazioni
| Rischio | file .torrent | Link magnetico |
|---|---|---|
| Stalle senza eguali | Aspetta i colleghi | Potrebbe non ricevere mai i metadati |
| Contenuti falsi o etichettati in modo errato | Possibile | |
| Esposizione legale | Dipende dal contenuto e dalla giurisdizione. Ospitare il file può comportare una maggiore esposizione per i gestori del sito. | Dipende dal contenuto e dalla giurisdizione. La condivisione di link a volte viene trattata diversamente dall'hosting di file, ma questo varia e non è una garanzia di protezione. |
| esposizione della privacy | Tracciamento e visibilità tra pari | DHT e visibilità tra pari |
| Morte del tracker | Riduce la scoperta, ma il DHT potrebbe comunque funzionare | Nessun problema se il collegamento si basa sul DHT |
| Durata a lungo termine | Meglio | Peggio |
| Errori di battitura e troncamento | È stato rilevato un file danneggiato | Un errore di battitura nell'hash non porta a nulla e un link troncato viene interrotto silenziosamente. |
9. Compatibilità e usabilità
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Assistenza clienti | Universale | Universale nei client moderni (richiede BEP 9) |
| Seedbox e servizi web | Sostenuto universalmente | Perlopiù supportato, anche se alcuni servizi più vecchi accettano solo file |
| Compatibilità con i dispositivi mobili | Difficoltà moderata (la gestione dei file scaricati è macchinosa) | Alto |
| Automazione (RSS, script, API) | Semplice | Inoltre, è semplice e più facile da riporre. |
| leggibilità umana | Non leggibile senza uno strumento | L'hash è opaco, ma la struttura è leggibile. |
10. Come creare file .torrent e link magnet
Gli elementi contrassegnati da un pugnale rappresentano mie considerazioni personali o conoscenze generali, non confermate da fonti ufficiali.
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Input iniziale | I tuoi file o la tua cartella, più uno strumento di creazione (ad esempio mktorrent o la funzione "crea torrent" del client) | Un info-hash esistente. Nella v1 si tratta dell'SHA-1 del dizionario info bencoded, quindi un link magnet non può esistere prima che esistano i metadati .torrent |
| Sequenza dei passaggi | 1) Scegli la lunghezza del pezzo. 2) Calcola l'hash di ogni pezzo. 3) Crea il dizionario delle informazioni. 4) Aggiungi campi esterni come i tracker. 5) Codifica Bencode e salva. | 1) Scarica il torrent. 2) Prendi il suo info-hash. 3) Scrivi l'URI con xt. 4) Facoltativamente aggiungi dn, tr e x.pe |
| Lunghezza del pezzo | Lo scegli tu. È quasi sempre una potenza di due, più comunemente 256 KiB. mktorrent imposta di default 2^18 byte e lo imposta con -l | Nessuno; è ereditato dal torrent |
| lavoro di hashing | Ogni byte viene sottoposto ad hashing: SHA-1 per la versione 1, SHA-256 per file con alberi Merkle per la versione 2. Il tempo aumenta con la dimensione dei dati (dagger) e mktorrent può utilizzare diversi thread. | Trascurabile: niente oltre l'hash esistente |
| Tracciatori | annuncia o lista di annunci. La lista si trova al di fuori della sezione informazioni; se presente, i client compatibili ignorano l'annuncio e i livelli vengono provati in ordine, con gli URL all'interno di un livello mescolati | tr= parametri nell'URI. Se non ne vengono forniti, i client devono utilizzare il DHT |
| Mappa privata | Impostandolo inserendo private=1 nel dizionario info. I client conformi si annunceranno quindi solo al tracker privato e si connetteranno solo ai peer che questo restituisce. Poiché si trova all'interno di info, influisce sull'info-hash (dagger). | Nel link non è presente alcun campo apposito. Il flag si trova nei metadati, che il client visualizza solo dopo averli recuperati (dagger). |
| Semi di rete | url-list, secondo BEP 19. mktorrent lo espone come -w. Il server HTTP/FTP funge da seed permanentemente non bloccato | ws= non fa parte dell'elenco dei parametri di BEP 9. Trattalo come un'estensione dipendente dal client. |
| Campi descrittivi facoltativi | Il commento e la data di creazione sono facoltativi. mktorrent offre l'opzione -c per aggiungere un commento e -d per omettere la data. | Solo dn (nome visualizzato). È un'etichetta e non verificato |
| Tag sorgente | mktorrent’s -s incorpora una stringa sorgente nell'info-hash, in modo che gli stessi file con un tag diverso ottengano un hash diverso e uno swarm separato | Non applicabile |
| Cosa cambia l'identità? | Qualsiasi informazione interna: nome, lunghezza del pezzo, flag privato, tag sorgente, elenco file (dagger) | Cambiare xt punta a un torrent diverso. Cambiare dn, tr o x.pe non |
| Scelta della versione hash | v1 (SHA-1), v2 (SHA-256) o ibrido, scelto in fase di creazione | Il link deve contenere btih, btmh o entrambi per un ibrido (BEP 9 consente entrambi gli argomenti in un unico magnet se descrivono lo stesso torrent ibrido) |
| Firma | BEP 35 consente l'incorporamento di firme RSA nel file, facoltativamente con un certificato X.509, e diverse firme per torrent. È usato raramente (dagger). | BEP 9 non definisce alcun campo per la firma, quindi non c'è nulla da firmare. |
| Produzione | Un file binario da KB a MB, che devi ospitare o inviare | Una riga di testo di poche centinaia di byte |
| Renderlo utilizzabile | Carica il file ed esegui un client con i dati originali in posizione in modo da poter eseguire il seeding | Pubblica la riga e continua a condividere i dati. Il link non serve a nulla se nessun altro peer possiede i dati e i metadati. |
| Errori tipici | Dimensioni del pezzo errate rispetto alle dimensioni del contenuto (dagger); dimenticanza del flag privato prima della pubblicazione, poiché modificarlo in seguito comporta un nuovo hash (dagger); aggiunta del tracker errato | Errore di battitura o troncamento nell'hash, quindi il link non punta silenziosamente da nessuna parte (dagger); prefisso errato (btih vs btmh); caratteri speciali non preceduti da escape in dn (dagger) |
11. Utilizzando ciascuno di essi
Gli elementi contrassegnati da un pugnale rappresentano mie considerazioni personali o conoscenze generali, non confermate da fonti ufficiali.
| Aspetto | file .torrent | Link magnetico |
|---|---|---|
| Come aprirlo | Fai doppio clic sull'associazione del file, trascinalo in un client oppure usa "Aggiungi file torrent" | Fai clic su un magnete: link (richiede un gestore registrato), incollalo in un client oppure scansiona un codice QR (pugnale) |
| Cosa fa prima il cliente | Analizza le metainformazioni codificate in ben | Analizza l'URI ed estrae l'info-hash |
| Da dove provengono i metadati | Già nel file | I peer inviano il dizionario delle informazioni (solo quella parte del .torrent) in blocchi da 16 KiB tramite l'estensione BEP 9 e il client lo controlla rispetto all'hash |
| Trovare i pari | Tracker dal file, più DHT/PEX/LSD a meno che il torrent non sia privato. Per i torrent privati, DHT e PEX non devono essere utilizzati | Tracker nel link; se non ce ne sono, il DHT |
| Ritardo di avvio | Nessuno | Attende che un peer in possesso dei metadati risponda, quindi può rimanere bloccato indefinitamente. |
| Selezione dei file prima del download | Immediatamente | Dopo l'arrivo dei metadati. Alcuni client possono recuperare solo i metadati, per visualizzare in anteprima l'elenco dei file prima del download |
| Ispezionare prima di impegnarsi | Ispezione completa con qualsiasi strumento di analisi, offline | Impossibile finché non vengono recuperati i metadati. |
| Conversione tra di loro | Calcola l'info-hash e scrivi un link magnetico (dagger) | I metadati recuperati possono essere esportati e memorizzati nella cache come torrent, in modo che lo stesso magnet link non necessiti mai di un secondo download dei metadati. |
| Utilizzo di tracker privati | Funziona, poiché il file contiene l'URL del tracker e i client devono limitarsi a utilizzarlo (BEP 27) | Probabilmente impraticabile: il link non ha un flag e un URL di tracciamento può contenere credenziali personali (dagger). La norma BEP 27 non tratta i magneti. |
| Modifica | È possibile aggiungere o rimuovere tracker senza modificare l'hash, poiché si trovano al di fuori della sezione informazioni. La modifica delle informazioni crea un nuovo torrent. | Modifica liberamente il testo; alterando xt cambia quale torrent è |
| Verifica dell'autenticità | Verifica la firma BEP 35 confrontandola con un certificato di cui ti fidi. Una biblioteca fa notare che il suo controllo non convalida il certificato stesso. In caso contrario, esamina l'elenco dei file. | Confronta l'info-hash con quello di una fonte attendibile; non è disponibile nient'altro |
| Aggiornamento automatico | BEP 39 consente a un creatore di inserire un URL di aggiornamento nel dizionario info, e i client scaricano automaticamente i torrent più recenti solo se firmati dall'autore originale | Nessuno |
| Continua a condividere | Invia o ospita il file | Copia e incolla la riga |
| Quando fallisce | Tracker non funzionante o nessun peer: il client attende. Un file danneggiato viene rifiutato. | Errore di battitura nell'hash o peer non raggiungibile: bloccato su "recupero dei metadati" |
| Recupero del seme web | Un file .torrent con un seed web funziona anche senza peer. I link magnet non hanno un equivalente, perché né BEP 9 né i BEP di seeding HTTP forniscono un modo per recuperare i metadati dai seed HTTP. | |
| Dopo il download | Continua a utilizzare gli stessi file per il seeding. | |
Riepilogo
I file torrent (.torrent) sono ideali per l'archiviazione, i tracker privati, la visualizzazione preliminare dell'elenco dei file e i metadati offline, mentre i magnet link eccellono nella condivisione rapida, nei codici QR, nella distribuzione indipendente dai tracker e nell'hosting minimo.
Nessuno dei due formati è intrinsecamente più sicuro. Entrambi verificano l'integrità dei dati tramite crittografia, ma nessuno dei due autentica chi ha pubblicato il contenuto o di cosa si tratti effettivamente. Il vero rischio per la sicurezza e per la legalità deriva dal contenuto e dalla fonte, quindi controllate l'elenco dei file per individuare estensioni sospette e fate attenzione alla provenienza del link.
Domande frequenti
BitTorrent è uno standard IETF o ISO? E qual è il livello di formalità dei file .torrent e dei link magnet?
No. Il protocollo è specificato tramite le BitTorrent Enhancement Proposals (BEP), un processo modellato sulle PEP di Python. La BEP 3 definisce il formato metainfo e la BEP 52 definisce la versione 2. La BEP 9, che riguarda lo scambio di metadati e il formato magnet di BitTorrent, ha lo stato "Accepted", non "Final". Lo schema magnet: stesso è solo una registrazione provvisoria IANA, con il Magnet-URI Project come creatore. In pratica, l'interoperabilità è definita dalle principali librerie client, quindi è consigliabile testare diverse implementazioni.
L'info-hash lega crittograficamente un torrent al suo contenuto?
Transitivamente, sì. L'info-hash v1 è l'SHA-1 del dizionario info codificato in bencode, e quel dizionario contiene l'hash SHA-1 di ogni elemento, quindi l'hash viene associato ai dati. Il problema è la minore resistenza alle collisioni di SHA-1: esistono collisioni pratiche, quindi un editore che crea entrambe le varianti di un torrent potrebbe generare due payload con un solo hash. Gli attacchi di seconda preimmagine contro un torrent esistente rimangono impraticabili. La versione v2 passa a SHA-256 ed elimina questo problema.
Quali modifiche cambiano l'identità di un torrent e quali no?
Qualsiasi elemento all'interno del dizionario info modifica l'info-hash: nome, elenco dei file, lunghezza del pezzo, flag privato e un tag sorgente come l'opzione -s di mktorrent. I campi esterni, come announce e announce-list (BEP 12), possono essere modificati liberamente senza creare un nuovo torrent. In un link magnet, dn, tr e x.pe non influiscono mai sull'identità; solo xt lo fa. La modifica del dizionario info crea silenziosamente un fork dello swarm, quindi va considerata come la pubblicazione di un nuovo torrent.
Come fa un client ad autenticare i metadati ricevuti tramite un link magnet?
I peer inviano il dizionario delle informazioni in blocchi da 16 KiB tramite l'estensione BEP 9 ut_metadata, e il client calcola l'hash del risultato assemblato confrontandolo con l'hash delle informazioni del link. I metadati falsificati vengono rifiutati a meno che l'attaccante non riesca a decifrare l'hash. Questo dimostra l'integrità relativa al link, non la veridicità. Il valore dn è un'etichetta non verificata e l'hash non dice nulla su chi ha pubblicato il contenuto o cosa contiene realmente.
Quali sono le differenze pratiche tra i torrent v1, v2 e ibridi?
La versione 1 utilizza un elenco semplice di hash SHA-1 dei frammenti nel dizionario delle informazioni. La versione 2 (BEP 52) utilizza SHA-256 con un albero Merkle per file e un albero gerarchico dei file. I layer dei frammenti si trovano al di fuori del dizionario delle informazioni e le implementazioni devono confrontarli con i campi radice dei frammenti al suo interno. Un torrent ibrido contiene entrambe le strutture e quindi ha due hash delle informazioni, e un link magnet può contenere sia argomenti btih che btmh. Verifica che il tuo client e gli strumenti supportino la versione 2 prima di pubblicare torrent che utilizzano solo la versione 2.
Un link magnet può avviare un download anche in assenza di peer, ma se esiste un seed web HTTP?
No. BEP 9 recupera i metadati solo dai peer e né BEP 9 né i BEP di seeding HTTP (17, 19) definiscono un modo per recuperare i metadati da un seed HTTP. Un file .torrent con un seed web funziona comunque anche con zero peer, perché i metadati sono già presenti nel file. Se la disponibilità dipende dai seed web, distribuisci il file .torrent, non solo un link magnet.
Quali informazioni sulla mia privacy e sulla mia identità online rivela ciascun formato?
Entrambi espongono il tuo indirizzo IP ai peer e a qualsiasi tracker a cui ti comunichi. I link magnet in genere dipendono dal DHT pubblico, che aggiunge un ulteriore percorso di ricerca in cui compaiono il tuo IP e l'info-hash. La crittografia del protocollo offusca il traffico ma non ti rende anonimo. I torrent privati (BEP 27) richiedono ai client di utilizzare solo il tracker privato, quindi DHT e PEX non vengono utilizzati. Per i requisiti di anonimato, è necessario utilizzare un modello di minaccia con un'adeguata mitigazione a livello di rete, non una scelta di formato.
Come posso verificare l'autenticità, e non solo l'integrità, dei dati ottenuti tramite torrent?
La verifica dei singoli file dimostra solo che i dati corrispondono al torrent. Per garantire l'autenticità, è necessario ottenere un checksum o una firma (ad esempio un manifesto SHA-256 firmato) tramite un canale indipendente e affidabile e confrontare i file finali con tale firma. Lo standard BEP 35 definisce le firme RSA incorporate nei file .torrent, con certificati X.509 opzionali e firmatari multipli, ma è raramente utilizzato e una libreria che lo implementa specifica che la sua verifica non convalida il certificato stesso. I link magnet non prevedono alcun meccanismo di firma.
Come devo scegliere la lunghezza del file quando creo un torrent?
Si tratta di un compromesso tra la dimensione dei metadati e la granularità del trasferimento. BEP 3 afferma che la lunghezza dei pezzi è quasi sempre una potenza di due, comunemente 256 KiB, che è anche il valore predefinito di mktorrent. Nella versione 1, un payload di 100 GiB a 256 KiB ha 409.600 pezzi, quindi la sola stringa dei pezzi è di circa 8 MB. I client magnet devono scaricare l'intero dizionario in circa 500 blocchi prima di iniziare, quindi metadati sovradimensionati rallentano l'avvio del magnet. Pezzi più grandi riducono le dimensioni dei metadati ma rendono più grossolana la riparazione dopo un pezzo non funzionante.
Perché due torrent di dati identici finiscono in swarm separati e come posso evitarlo?
Poiché l'info-hash copre l'intero dizionario delle informazioni, nomi diversi, ordine dei file, lunghezze dei frammenti, flag privati o tag sorgente producono hash diversi anche per payload identici a livello di byte. Per mantenere un unico swarm, standardizzate la lunghezza dei frammenti, il nome, l'ordine dei file e i flag nel vostro processo di rilascio e pubblicate l'info-hash insieme all'artefatto. I tag sorgente sono un modo intenzionale per separare gli swarm e l'opzione -s di mktorrent modifica deliberatamente l'hash.
Quali sono le principali problematiche di sicurezza quando si scrive un client o un parser per questi formati?
Trattare tutti gli input come non attendibili. Convalidare rigorosamente il bencode, limitare la dimensione dei metadati (un client open-source impone un limite di 32 MB) e sanificare i percorsi dei file dai metadati per prevenire l'attraversamento delle directory. Filtrare gli indirizzi privati e di loopback restituiti dai tracker e dalla DHT per limitare gli abusi di tipo SSRF e verificare che gli URL dei tracker siano accettabili prima di connettersi. Trattare il dn come testo non attendibile e verificare l'hash di ogni elemento prima di scriverlo nella memoria di archiviazione finale.
Come posso calcolare correttamente l'info-hash di un file .torrent?
Individua l'intervallo esatto di byte del valore info così come appare nel file e calcola l'hash di quei byte: SHA-1 per la versione 1 o SHA-256 per la versione 2. BEP 3 sottolinea che l'hash deve essere calcolato sulla codifica presente nel file. Decodificare e ricodificare il dizionario è sicuro solo se il decodificatore ha convalidato completamente l'input, e un decodificatore permissivo può normalizzare silenziosamente i dati e produrre un hash diverso. Per i torrent ibridi, calcola entrambi gli hash dallo stesso intervallo.
Posso utilizzare un link magnet per un torrent da un tracker privato?
Spesso non è pratico. BEP 27 richiede ai client di annunciarsi solo al tracker privato e di connettersi solo ai peer che questo restituisce. Un link magnet semplice non contiene il flag di "privato", poiché questo risiede nei metadati, e potrebbe non includere un URL del tracker utilizzabile. Se è incorporato un URL del tracker con le credenziali, trattate il link come un segreto. Questa è la mia deduzione dalla specifica, perché BEP 27 non affronta direttamente i link magnet, quindi testatelo con le regole del vostro tracker.
Per distribuire software, dataset o archivi in una pipeline, è meglio pubblicare un file .torrent o un link magnet?
Pubblica entrambi i file, con il file .torrent come artefatto canonico. In questo modo si preservano i metadati completi, si consente agli utenti di esaminare l'elenco dei file offline e si supporta la condivisione tramite web seed (BEP 19) per garantirne la disponibilità. Per comodità, si può ricavare il link magnet dallo stesso info-hash e pubblicare l'info-hash, insieme a un checksum firmato, su un canale affidabile. Questo garantisce la durabilità dell'archiviazione e una facile condivisione, senza che il recupero dei metadati dipenda dai peer.
Quali fattori determinano per quanto tempo un file torrent rimane recuperabile e come posso ottimizzare questa funzionalità?
La recuperabilità richiede almeno un peer raggiungibile che detenga i dati e, nel caso di link magnet, anche un peer che detenga i metadati. Per migliorarla, è consigliabile mantenere i seed attivi, aggiungere più tracker in livelli (BEP 12) come backup, aggiungere seed web HTTP e mantenere il file .torrent archiviato o esportabile dai client che memorizzano nella cache i metadati recuperati. Un link magnet da solo non conserva nulla, quindi uno swarm inattivo lo rende inutile.
Elenco esteso di letture e argomenti correlati
- Codifica Ben: il formato di serializzazione utilizzato dai file .torrent, con chiavi del dizionario ordinate
- Info-hash: Digest SHA-1 (v1) o SHA-256 (v2) del dizionario di informazioni bencoded, l'identità del torrent
- Archiviazione indirizzabile per contenuto: identificare i dati tramite il loro hash anziché la loro posizione
- Alberi di Merkle: Alberi hash per file in BitTorrent v2 (BEP 52) per la verifica a livello di singolo pezzo.
- Torrent ibridi: singoli torrent contenenti sia la struttura v1 che la struttura v2 e due info-hash
- Lunghezza del pezzo e numero di strati del pezzo: il compromesso tra dimensione dei metadati e granularità della verifica
- Resistenza alle collisioni SHA-1: perché l'hashing v1 è teoricamente indebolito e v2 passa a SHA-256
- Protocollo di estensione (BEP 10): il meccanismo di handshake che abilita ut_metadata, PEX e altre estensioni
- Scambio di metadati (BEP 9, ut_metadata): recupero del dizionario delle informazioni dai peer in blocchi da 16 KiB
- Schema URI Magnet: uno schema di identificazione basato su hash, indipendente dal progetto, con registrazione IANA provvisoria.
- MAGMA (manifestazione magnetica): il concetto di tema manifesto dalle origini multi-rete dello schema magnet
- Selezione del file magnet (BEP 53): scegliere file specifici all'interno di un torrent dal link stesso
- Metadati multitracker (BEP 12): livelli di lista di annuncio con rimescolamento e failover
- UDP Protocollo di tracciamento (BEP 15): Annuncio del tracker leggero tramite UDP
- Liste compatte di pari (BEP 23): la codifica binaria compatta dei peer nelle risposte del tracker
- Estensione di tracciamento IPv6 (BEP 7): peers6 annuncia il supporto per IPv6
- Segnalazione IP esterna del tracker (BEP 24): tracker che comunicano ai clienti il loro indirizzo osservato
- DHT principale (BEP 5): La tabella hash distribuita basata su Kademlia per la scoperta di peer senza tracker
- Estensione di sicurezza DHT (BEP 42): limitazione degli ID dei nodi per resistere agli attacchi Sybil e alle tabelle di routing
- Indicizzazione DHT put/get e infohash (BEP 44, BEP 51): memorizzazione dei dati e campionamento degli info-hash nella DHT
- Scambio peer, PEX (BEP 11): I membri dello sciame condividono direttamente gli elenchi dei pari
- Individuazione dei servizi locali (BEP 14): trovare pari nello stesso segmento di rete
- Estensione rapida (BEP 6): scorciatoie di protocollo come have-all, have-none e reject
- uTP (BEP 29): un trasporto basato su UDP con controllo della congestione basato sul ritardo
- Estensione foratura (BEP 55): Attraversamento NAT coordinato tramite peer di inoltro
- Crittografia del flusso di messaggi (MSE/PE): offuscamento del protocollo, non anonimato
- Torrent privati (BEP 27): il flag privato che limita la scoperta dei peer al tracker
- Inseminazione della rete (BEP 17, BEP 19): Server HTTP o FTP che fungono da seed permanenti
- File di riempimento (BEP 47): allineamento dei file ai limiti dei blocchi per la deduplicazione e il supporto ibrido
- Suggerimenti sui dati locali (BEP 38): riutilizzare i dati da torrent correlati per evitare di scaricarli nuovamente
- Firma del torrent (BEP 35): Firme RSA incorporate con certificati X.509 opzionali
- Aggiornamenti dei feed torrent (BEP 39): URL di aggiornamento per i torrent firmati e successori automatici
- Flusso di verifica dei componenti: controllo hash prima del commit e ripristino da parti non riuscite
- Protezione del parser e del client: codice di condotta rigoroso convalidalimiti di dimensione, sanificazione del percorso, filtro SSRF
- WebTorrent e WebRTC: peer basati su browser che utilizzano tracker ws/wss e ICE o TURN
- Sementiere e semina a lungo termine: infrastruttura per la disponibilità e la persistenza archivistica
- Processo e governance del BEP: come le specifiche vengono proposte, indicizzate e promosse da Accettate a Finali
- Sistemi alternativi basati sui contenuti: Identificatori di contenuto in stile IPFS come modello comparabile
- Provenienza contro integrità: Perché gli hash verificano i dati ma non autenticano mai chi li pubblica?
Collegamenti esterni su Torrent
(passa il mouse sul link per vedere la nostra descrizione del contenuto)
