A .torrent file and a ímã link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- Um arquivo .torrent é um arquivo de "metainformações". Seu dicionário de informações contém o comprimento do fragmento, o nome e o tamanho do arquivo (ou uma lista de arquivos) e, na versão 1, uma lista concatenada de hashes SHA-1 de 20 bytes, um para cada fragmento. O hash de informações é o SHA-1 de 20 bytes do valor de informações codificado, calculado sobre a forma codificada exatamente como aparece no arquivo .torrent. Os URLs dos rastreadores ficam fora desse dicionário, portanto, podem ser alterados sem afetar a identidade do torrent. O BitTorrent v2 (BEP 52) altera o hash: ele usa SHA-256 com uma árvore Merkle por arquivo e uma árvore hierárquica de arquivos. As "camadas de fragmento" por arquivo ficam fora do dicionário de informações, e as implementações deve verifique-os em relação aos campos raiz das peças dentro dele. bep 0003 +2
- Um link magnético não contém metadados, apenas a identidade do link. Seu formato é magnet:?xt=urn:btih: para v1 ou xt=urn:btmh: para v2, com parâmetros opcionais de nome de exibição (dn), rastreador (tr) e endereço do par (x.pe). Um torrent híbrido pode conter tópicos btih e btmh em um único link. Para começar, o cliente busca os metadados de outros pares usando a extensão BEP 9. Essa extensão transfere apenas a parte do dicionário de informações do arquivo .torrent, em blocos de 16 KiB. O cliente então verifica se o hash está presente no link. Se o link não mencionar nenhum rastreador, o cliente deve usar a DHT para encontrar pares. bep 0009 +2
Assim, os dois formatos apontam para o mesmo enxame e fornecem o mesmo download assim que ele é iniciado. Eles diferem na origem dos metadados:
Um arquivo .torrent é um artefato estático: a lista de arquivos é conhecida imediatamente, os metadados sobrevivem a um enxame de torrents inativo e o arquivo precisa ser hospedado em algum lugar.
Um link magnético é uma pequena sequência de caracteres que pode ser colada em qualquer lugar, mas só funciona enquanto pelo menos um servidor acessível ainda possuir os metadados. Nenhum dos formatos autentica o editor ou confirma se o conteúdo corresponde ao seu rótulo. O hash apenas comprova que os dados correspondem ao hash.
Dica: A pedido do público, este post serve como suporte para todas as nossas postagens sobre torrents e P2P para projetos de engenharia.
História e contexto
O formato .torrent deriva do projeto original do BitTorrent. Bram Cohen criou o protocolo em abril de 2001 e lançou a primeira versão em 2 de julho de 2001. Ele e Ashwin Navin fundaram a BitTorrent, Inc. (posteriormente Rainberry, Inc.) em 2004. Cohen também é o autor listado do BEP 3, a especificação principal que define o arquivo de metadados e o info-hash. O desenvolvimento subsequente é coordenado por meio do processo de Propostas de Aprimoramento do BitTorrent (BIP), que foi modelado a partir das PEPs do Python, e Cohen desejava que o cliente principal permanecesse de código aberto.
A especificação BEP 3 é o documento mais próximo de uma autoridade formal para o assunto. formato de arquivoO formato v2 surgiu muito mais tarde: a BitTorrent, Inc. lançou a especificação v2 em 15 de maio de 2017. Os links magnéticos têm uma origem diferente. O esquema `magnet:` não foi inventado para o BitTorrent. Ele foi projetado como uma forma independente de projeto para identificar arquivos por hash de conteúdo em diversas redes P2P. A IANA o lista apenas como um esquema provisório, registrado em 2012 com o Projeto Magnet-URI como seu criador. Fontes secundárias datam sua introdução em 2002, mas não encontrei nenhuma fonte primária para essa data. O uso de links magnéticos pelo BitTorrent se baseia no BEP 9, de autoria de Greg Hazel e Arvid Norberg (Norberg também é o autor original da libtorrent). A BEP 9 ainda está apenas "Aceita", não Final, e ganhou o parâmetro x.pe peer-address em 2016. Essa BEP define tanto o protocolo de troca de metadados quanto o formato magnet do BitTorrent, mas as anotações de um implementador descrevem os URIs magnet como uma convenção de fato, não como uma BEP numerada.
Na prática, ambos os formatos se baseiam no processo BEP e no que os principais clientes implementam, e não em um formato formal. padrões corpo.
1. Fundamentos
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| O que é isso? | Um pequeno arquivo binário (dicionário bencoded) | Um URI de texto (magnet:?xt=urn:btih:…) |
| Contém o conteúdo? | Não, apenas metadados. | Não, apenas um identificador. |
| Conteúdo principal | URLs de rastreamento, nomes e tamanhos dos arquivos, duração de cada fragmento, hash de cada fragmento, comentário opcional, criador e data. | Info-hash (xt), nome de exibição opcional (dn), rastreadores (tr), endereços de pares (x.pe); sementes da web (ws) apenas como uma extensão dependente do cliente, não definida no BEP 9 |
| Tamanho típico | De alguns KB a vários MB (aumenta com o tamanho do conteúdo) | Cerca de 100 a 500 bytes |
| Identificador utilizado | Hash de informações SHA-1 (v1), SHA-256 (v2) ou ambos (híbrido) | O mesmo hash de informações: urna:btih (v1) ou urn:btmh (v2) |
| Especificação | BEP 3 (v1), BEP 52 (v2) | BEP 9 (formato de URI de troca de metadados e magnet link) |
| manipulador de protocolo | Aberto por associação de arquivo (.torrent) | Aberto pelo sistema operacional ou pelo navegador (ícone de URI): manipulador de URI |
2. Metadados e informações do arquivo
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| A lista de arquivos fica visível antes do início do download. | Sim, imediatamente | Não, somente depois que os metadados forem obtidos dos pares. |
| Fonte de metadados | Incorporado no arquivo | Baixado de pares (DHT, PEX, rastreadores) via ut_metadata |
| Integridade dos metadados | Verificado por hashing | Verificado em relação ao info-hash no link, portanto, metadados adulterados são rejeitados. |
| Atraso inicial | Nenhum | De segundos a minutos (ou nunca, se nenhum par tiver os metadados) |
| Nome de exibição | Armazenado no arquivo (nome) | O parâmetro `dn` é opcional e não verificado; trata-se apenas de um rótulo. |
| Fragmentos de pedaços | Incluído | Obtido posteriormente com os metadados |
| Editável | É possível editar os rastreadores sem alterar o hash. Editar o dicionário de informações altera o hash de informações, criando um torrent diferente. | Fácil de editar como texto (adicionar ou remover rastreadores). O info-hash não pode ser alterado sem apontar para um conteúdo diferente. |
3. Autoria, Proveniência e Autenticidade
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Informações sobre o autor | Campos opcionais: criado por (cliente e versão), data de criação, comentário | Nenhum; não existe um campo de autor padrão. |
| Vazamento de metadados sobre o criador | Possível (versão do cliente, carimbo de data/hora, às vezes comentários ou URLs) | Mínimo; o link contém apenas o que quem compartilhou incluiu. |
| Assinatura digital | Existe uma extensão para assinatura (BEP 35), mas ela raramente é usada. | Nenhum |
| Comprovante: o conteúdo corresponde ao que está descrito no rótulo. | Nenhuma, e o nome pode ser falsificado. | Nenhum, e o DN pode ser falsificado. |
| Comprove que o conteúdo corresponde ao hash. | Sim, cada item é verificado por hash. | Sim, cada item é verificado por hash após a análise dos metadados. verificação |
| Modelo de confiança | Você confia em quem forneceu o arquivo e, em seguida, verifica os dados comparando-os com os hashes. | Você confia em quem forneceu o link, então verifique da mesma forma. |
| Risco de falsificação | Torrents falsos com o mesmo título são comuns. | Igualmente, e o link tem ainda menos contexto (não há lista de arquivos para inspecionar primeiro). |
4. Hospedagem, Distribuição e Disponibilidade
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Necessita de hospedagem | Sim, um servidor web, um site de índice ou um compartilhamento de arquivos. | Não; é apenas texto e pode ser colado em qualquer lugar. |
| Métodos de compartilhamento | Baixar, anexar por e-mail, transferir arquivos (anexos podem ser bloqueados em alguns casos) | Chat, corpo do e-mail, código QR, postagem no fórum, aplicativo de notas |
| Exposição de derrubada | Os arquivos hospedados podem ser removidos ou bloqueados. | Mais difícil de remover (texto puro), mas os sites que os publicam ainda podem ser bloqueados. |
| Link rot | O arquivo sobrevive enquanto o host existir. | O texto sobrevive, mas é inútil se nenhum outro pesquisador ainda possuir os metadados. |
| Valor de arquivamento | Alto: preserva os metadados completos mesmo quando o enxame está morto. | Baixa: depende de um enxame ativo para recuperar metadados. |
| Sites de indexação e pesquisa | É necessário armazenar um arquivo por torrent (mais espaço de armazenamento) | Armazene apenas um pedaço curto de barbante (mais barato e mais fácil de duplicar). |
| conveniência entre dispositivos | Precisa de transferência de arquivo | Fácil: copie e cole ou escaneie um código QR. |
| Comportamento do navegador | Baixa um arquivo e depois o abre em um cliente. | Aciona uma solicitação do manipulador de protocolo (requer um cliente registrado) |
5. Comportamento e desempenho da rede
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Descoberta por pares | Os rastreadores estão listados no arquivo, além de DHT, PEX e LSD (a menos que sejam privados). | DHT, PEX e LSD, além de quaisquer outros rastreadores de TR no link. |
| Funciona sem nenhum rastreador. | Somente se o DHT for permitido. | Sim, com DHT (este é o seu modo de ação habitual). |
| Dependência de DHT | Opcional | Frequentemente essencial para metadados e pares. |
| Sementes da Web (fontes HTTP) | campos url-list / httpseeds (BEP 19) | ws= parâmetro, uma extensão dependente do cliente não definida no BEP 9 |
| Velocidade de download após a execução | Idêntico | |
| Comportamento com torrents mortos ou raros | Inicia e aguarda os pares. | Pode haver uma interrupção em "recuperando metadados" |
| Rastreadores privados | Totalmente compatível (flag privada, senha no URL de anúncio) | Geralmente inutilizável. Torrents privados desativam DHT/PEX e a senha do rastreador não é exposta em um link compartilhável. |
6. Segurança
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Fonte de risco de malware | O conteúdo baixado, não o formato. | O conteúdo baixado, não o formato. |
| Risco do analisador sintático ou do manipulador | Bencode malformado pode causar erros em um cliente mal escrito (raro). | Parâmetros DN ou URI maliciosos podem causar injeção ou erros de exibição em clientes ou manipuladores mal escritos (raro). |
| Possibilidade de inspecionar antes de baixar | Alta: você pode ver a lista de arquivos, extensões e tamanhos primeiro. | O nível de arquivo fica baixo até a chegada dos metadados; a maioria dos clientes permite que você revise a lista de arquivos antes de baixar. |
| Executáveis disfarçados | Detectável na lista de arquivos (.exe, .scr, .lnk, etc.) | O mesmo acontece, mas somente após a obtenção dos metadados. |
| Riscos de phishing e anúncios | Sites de torrent costumam ter muitos anúncios. | Igual, além de cliques acidentais em botões magnéticos semelhantes. |
| Força do hash | SHA-1 para v1 (teoricamente frágil a colisões, difícil de explorar em torrents); SHA-256 para v2 | O mesmo hash do torrent para o qual ele aponta. |
| Adulteração durante o transporte | Detectado por meio de hashes de fragmentos | Detectado através do info-hash, embora um link trocado aponte para um conteúdo completamente diferente. |
7. Privacidade e Anonimato
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Seu endereço IP visível para seus pares | Sim | |
| Seu endereço IP visível para rastreadores | Sim (rastreadores incorporados) | Sim, se os rastreadores TR estiverem incluídos. |
| exposição ao DHT | Possível | Quase certo; suas pesquisas vão para o DHT público. |
| Diferença de anonimato | Nenhuma significativa | |
| Metadados que revelam quem compartilhou | O criador, o comentário e a data de criação podem revelar detalhes. | Nada além do que o texto do link contém. |
| Mitigações | VPN ou proxy, lado do cliente encryptionrastreadores privados | |
8. Riscos e Limitações
| Risco | Arquivo .torrent | Link magnético |
|---|---|---|
| Bancas sem igual | Aguarda os colegas | Pode ser que nunca consiga obter os metadados. |
| Conteúdo falso ou com rótulos incorretos | Possível | |
| Exposição legal | Depende do conteúdo e da jurisdição. Hospedar o arquivo pode acarretar maior exposição para os operadores do site. | Depende do conteúdo e da jurisdição. Compartilhar links às vezes é tratado de forma diferente de hospedar arquivos, mas isso varia e não constitui uma garantia absoluta. |
| Exposição à privacidade | Rastreador e visibilidade entre pares | DHT e visibilidade entre pares |
| Morte do rastreador | Reduz a detecção, mas o DHT ainda pode funcionar. | Não há problema se a ligação depender da DHT. |
| Durabilidade a longo prazo | Melhorar | Pior |
| Erros de digitação e truncamento | Um arquivo corrompido foi detectado. | Um erro de digitação no símbolo de cerquilha (#) aponta para lugar nenhum, e um link truncado é quebrado silenciosamente. |
9. Compatibilidade e Usabilidade
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Suporte ao cliente | Universal | Universal em clientes modernos (necessita de BEP 9) |
| Seedboxes e serviços web | Apoiado universalmente | Na maioria dos casos, há suporte, embora alguns serviços mais antigos aceitem apenas arquivos. |
| Compatibilidade com dispositivos móveis | Moderado (o processamento de arquivos baixados é complicado) | Alto |
| Automação (RSS, scripts, APIs) | Direto | Além disso, é simples e fácil de guardar. |
| Legibilidade humana | Não é possível ler sem uma ferramenta. | O hash é opaco, mas a estrutura é legível. |
10. Como criar arquivos .torrent e links magnéticos
Os itens marcados com uma adaga representam meu próprio raciocínio ou conhecimento geral, não confirmados por nenhuma fonte.
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Entrada inicial | Seus arquivos ou pasta reais, mais uma ferramenta de criação (por exemplo, mktorrent ou a função "criar torrent" do cliente). | Um hash de informações existente. Na versão 1, esse hash é o SHA-1 do dicionário de informações codificado em bencoded, portanto, um link magnet não pode existir antes dos metadados do .torrent. |
| Ordem dos passos | 1) Escolha o comprimento do fragmento. 2) Calcule o hash de cada fragmento. 3) Construa o dicionário de informações. 4) Adicione campos externos, como rastreadores. 5) Codifique e salve. | 1) Obtenha o torrent. 2) Obtenha o info-hash dele. 3) Escreva o URI com xt. 4) Opcionalmente, adicione dn, tr e x.pe. |
| Comprimento da peça | Você escolhe. Quase sempre é uma potência de dois, geralmente 256 KiB. O mktorrent usa 2^18 bytes por padrão e define esse valor com a opção -l. | Nenhuma; é herdada da torrente. |
| Trabalho de hashing | Cada byte é criptografado: fragmentos SHA-1 para a versão 1, árvores Merkle SHA-256 por arquivo para a versão 2. O tempo de processamento aumenta com o tamanho dos dados (dagger), e o mktorrent pode usar várias threads. | Negligenciável: nada além do hash existente. |
| Rastreadores | Anunciar, ou lista de anúncios. A lista fica fora da seção de informações; se presente, os clientes compatíveis ignoram o anúncio e os níveis são testados em ordem, com URLs dentro de um nível embaralhados. | tr= parâmetros no URI. Se nenhum for fornecido, os clientes devem usar o DHT. |
| Bandeira privada | Definido adicionando `private=1` ao dicionário `info`. Clientes compatíveis anunciam apenas para o rastreador privado e se conectam somente aos pares retornados por ele. Como está dentro do `info`, afeta o hash do `info` (dagger). | Não há campo para isso no link. A flag reside nos metadados, que o cliente só vê após buscá-la (dagger). |
| Sementes da teia | url-list, conforme BEP 19. O mktorrent o expõe como -w. O servidor HTTP/FTP atua como um seed permanentemente desbloqueado. | ws= não faz parte da lista de parâmetros do BEP 9. Trate-o como uma extensão dependente do cliente. |
| Campos descritivos opcionais | O comentário e a data de criação são opcionais. O mktorrent oferece a opção -c para adicionar um comentário e -d para omitir a data. | DN (nome de exibição) apenas. É um rótulo e não foi verificado. |
| Etiqueta de origem | O parâmetro -s do mktorrent incorpora uma string de origem no info-hash, de forma que os mesmos arquivos com uma tag diferente recebem um hash diferente e um enxame separado. | Não aplicável |
| O que muda a identidade | Qualquer informação interna: nome, tamanho do fragmento, sinalizador privado, tag de origem, lista de arquivos (adaga) | Alterar o arquivo xt aponta para um torrent diferente. Alterar os arquivos dn, tr ou x.pe não altera o resultado. |
| escolha da versão do hash | v1 (SHA-1), v2 (SHA-256) ou híbrido, escolhido na criação. | O link deve conter btih, btmh ou ambos para um híbrido (BEP 9 permite ambos os tópicos em um único magnet link se eles descreverem o mesmo torrent híbrido). |
| Assinatura | O BEP 35 permite assinaturas RSA incorporadas no arquivo, opcionalmente com um certificado X.509, e várias assinaturas por torrent. É raramente usado (dagger). | O BEP 9 não define nenhum campo de assinatura, portanto não há nada para assinar. |
| Saída | Um arquivo binário de KB a MB, que você deve hospedar ou enviar. | Uma linha de texto com algumas centenas de bytes |
| Tornando-o utilizável | Faça o upload do arquivo e execute um cliente com os dados originais para que você possa iniciar o processo de inicialização. | Publique a linha e continue semeando. O link não ajuda se nenhum par tiver os dados e metadados. |
| Erros típicos | Tamanho de fragmento incorreto para o tamanho do conteúdo (dagger); esquecimento da flag privada antes da publicação, pois alterá-la posteriormente significa um novo hash (dagger); adição do rastreador incorreto | Erro de digitação ou truncamento no hash, fazendo com que o link não aponte para lugar nenhum (†); prefixo incorreto (btih vs btmh); caracteres especiais não escapados em dn (†) |
11. Usando cada um
Os itens marcados com uma adaga representam meu próprio raciocínio ou conhecimento geral, não confirmados por nenhuma fonte.
| Aspecto | Arquivo .torrent | Link magnético |
|---|---|---|
| Como você abre isso | Clique duas vezes na associação de arquivos, arraste-o para um cliente ou use "Adicionar arquivo torrent". | Clique em um ímã: link (requer um manipulador registrado), cole-o em um cliente ou escaneie um código QR (adaga). |
| O que o cliente faz primeiro | Analisa os metadados codificadas. | Analisa o URI e extrai o info-hash. |
| De onde vêm os metadados? | Já está no arquivo | Os pares enviam o dicionário de informações (apenas essa parte do arquivo .torrent) em blocos de 16 KiB através da extensão BEP 9, e o cliente o verifica comparando-o com o hash. |
| Encontrando colegas | Rastreadores do arquivo, além de DHT/PEX/LSD, a menos que o torrent seja privado. Para torrents privados, DHT e PEX não devem ser usados. | Rastreadores no link; se nenhum, o DHT. |
| Atraso inicial | Nenhum | Aguarda até que um par com os metadados responda, podendo assim ficar em espera indefinidamente. |
| Selecionando os arquivos antes do download | Imediatamente | Após a chegada dos metadados. Alguns clientes podem obter apenas os metadados, para visualizar a lista de arquivos antes do download. |
| Inspecionar antes de se comprometer | Inspeção completa com qualquer ferramenta de análise sintática, offline | Não é possível até que os metadados sejam obtidos. |
| Convertendo entre eles | Calcule o info-hash e escreva um link magnético (dagger). | Os metadados obtidos podem ser exportados e armazenados em cache como um torrent, de forma que o mesmo link magnet nunca precise de um segundo download de metadados. |
| Uso de rastreador privado | Funciona, visto que o arquivo contém o URL do rastreador e os clientes devem restringir-se a ele (BEP 27). | Provavelmente impraticável: o link não possui um indicador e um URL de rastreamento pode conter credenciais pessoais (adaga). O BEP 27 não aborda ímãs. |
| Edição | Adicione ou remova rastreadores sem alterar o hash, pois eles estão fora da seção de informações. Editar as informações cria um novo torrent. | Edite o texto livremente; alterar xt muda qual torrent é. |
| Verificação de autenticidade | Verifique uma assinatura BEP 35 comparando-a com um certificado confiável. Uma biblioteca observa que sua verificação não valida o próprio certificado. Caso contrário, inspecione a lista de arquivos. | Compare o info-hash com um de uma fonte confiável; nada mais está disponível. |
| Atualizações automáticas | A BEP 39 permite que um criador insira um URL de atualização no dicionário de informações, e os clientes baixam automaticamente torrents mais recentes somente se assinados pelo criador. | Nenhum |
| Compartilhando adiante | Enviar ou hospedar o arquivo | Copie e cole a linha |
| Quando falha | Rastreador inativo ou sem pares: o cliente aguarda. Um arquivo corrompido é rejeitado. | Erro de digitação no hash ou nenhum peer alcançável: travado em "recuperando metadados"; |
| resgate de sementes da web | Um arquivo .torrent com um web seed ainda funciona mesmo sem outros servidores. Links magnéticos não têm equivalente, porque nem o BEP 9 nem os BEPs de seeding HTTP fornecem uma maneira de obter metadados dos seeds HTTP. | |
| Após o download | Continue semeando a partir dos mesmos arquivos. | |
Resumo
Os arquivos torrent (.torrent) são ideais para arquivamento, rastreadores privados, visualização prévia da lista de arquivos e metadados offline, enquanto os links magnéticos se destacam pelo compartilhamento rápido, códigos QR, distribuição independente de rastreadores e necessidade de hospedagem mínima.
Nenhum dos formatos é inerentemente mais seguro. Ambos verificam a integridade dos dados criptograficamente, e nenhum autentica quem publicou o conteúdo ou o que ele realmente é. O verdadeiro risco de segurança e legal vem do conteúdo e da fonte, portanto, verifique a lista de arquivos em busca de extensões suspeitas e tenha cuidado com a origem do link.
Perguntas frequentes
O BitTorrent é um padrão IETF ou ISO? E qual é o status formal dos arquivos .torrent e dos links magnéticos?
Não. O protocolo é especificado por meio de Propostas de Aprimoramento do BitTorrent (BEPs), um processo modelado a partir das PEPs do Python. A BEP 3 define o formato de metainformação e a BEP 52 define a versão 2. A BEP 9, que abrange a troca de metadados e o formato magnet do BitTorrent, possui o status "Aceito", e não "Final". O esquema `magnet:` em si é apenas um registro provisório da IANA, tendo o Projeto Magnet-URI como seu criador. Na prática, a interoperabilidade é definida pelas principais bibliotecas de cliente, portanto, teste com diversas implementações.
O info-hash vincula criptograficamente um torrent ao seu conteúdo?
Transitivamente, sim. O info-hash v1 é o SHA-1 do dicionário de informações codificado, e esse dicionário contém o hash SHA-1 de cada fragmento, portanto o hash é vinculado aos dados. A ressalva é a resistência a colisões enfraquecida do SHA-1: colisões práticas existem, então um editor que cria ambas as variantes de um torrent poderia criar duas cargas úteis com um único hash. Ataques de segunda pré-imagem contra um torrent existente permanecem inviáveis. A v2 migra para o SHA-256 e elimina essa preocupação.
Quais edições alteram a identidade de um torrent e quais não?
Qualquer alteração no dicionário de informações modifica o hash de informações: nome, lista de arquivos, tamanho do fragmento, a flag de privacidade e uma tag de origem, como a opção -s do mktorrent. Campos externos, como announce e announce-list (BEP 12), podem ser editados livremente sem a necessidade de criar um novo torrent. Em um link magnético, dn, tr e x.pe nunca afetam a identidade; apenas xt afeta. Alterar o dicionário de informações cria um fork silencioso do enxame, portanto, considere isso como a publicação de um novo torrent.
Como um cliente autentica os metadados recebidos por meio de um link magnético?
Os pares enviam o dicionário de informações em blocos de 16 KiB através da extensão ut_metadata do BEP 9, e o cliente calcula o hash do resultado montado e o compara com o hash de informações do link. Metadados falsificados são rejeitados, a menos que o atacante consiga quebrar o hash. Isso comprova a integridade em relação ao link, não a veracidade. O valor dn é um rótulo não verificado, e o hash não diz nada sobre quem publicou o conteúdo ou o que ele realmente contém.
Quais são as diferenças práticas entre torrents v1, v2 e híbridos?
A versão 1 usa uma lista simples de hashes SHA-1 no dicionário de informações. A versão 2 (BEP 52) usa SHA-256 com uma árvore Merkle por arquivo e uma árvore hierárquica de arquivos. As camadas de partes ficam fora do dicionário de informações, e as implementações devem verificá-las em relação aos campos raiz das partes dentro dele. Um torrent híbrido carrega ambas as estruturas e, portanto, possui dois hashes de informações, e um link magnético pode conter tópicos btih e btmh. Verifique se seu cliente e ferramentas suportam a versão 2 antes de publicar torrents somente com essa estrutura.
Um link magnético pode iniciar um download quando não há outros servidores conectados, mas existe um servidor web HTTP?
Não. O BEP 9 recupera metadados apenas de pares, e nem o BEP 9 nem os BEPs de seeding HTTP (17, 19) definem uma maneira de obter metadados de um seed HTTP. Um arquivo .torrent com um web seed ainda funciona com zero pares, porque os metadados já estão no arquivo. Se você depende de web seeds para disponibilidade, distribua o arquivo .torrent, não apenas um link magnet.
O que cada formato revela sobre minha privacidade e identidade na rede?
Ambos expõem seu endereço IP a outros usuários e a quaisquer rastreadores nos quais você anuncie sua identidade. Links magnéticos geralmente dependem do DHT público, o que adiciona outro caminho de busca onde seu IP e o hash de informações aparecem. A criptografia de protocolo ofusca o tráfego, mas não garante seu anonimato. Torrents privados (BEP 27) exigem que os clientes usem apenas o rastreador privado, portanto, DHT e PEX não são utilizados. Para requisitos de anonimato, utilize um modelo de ameaças com mitigação adequada em nível de rede, e não uma escolha de formato.
Como posso verificar a autenticidade, e não apenas a integridade, dos dados obtidos via torrent?
A verificação de partes apenas comprova que os dados correspondem ao torrent. Para autenticidade, obtenha um checksum ou assinatura (por exemplo, um manifesto SHA-256 assinado) por meio de um canal confiável independente e verifique os arquivos finalizados em relação a ele. O BEP 35 define assinaturas RSA incorporadas em arquivos .torrent, com certificados X.509 opcionais e múltiplos signatários, mas raramente é implementado, e uma biblioteca que o implementa observa que sua verificação não valida o próprio certificado. Links magnéticos não possuem nenhum mecanismo de assinatura.
Como devo escolher a duração dos fragmentos ao criar um torrent?
É uma questão de equilíbrio entre o tamanho dos metadados e a granularidade da transferência. O BEP 3 afirma que o tamanho dos fragmentos é quase sempre uma potência de dois, geralmente 256 KiB, que também é o padrão do mktorrent. Na versão 1, um payload de 100 GiB com 256 KiB possui 409.600 fragmentos, portanto, a string de fragmentos sozinha tem cerca de 8 MB. Os clientes Magnet precisam baixar todo esse dicionário em aproximadamente 500 blocos antes de iniciar, então metadados muito grandes tornam as inicializações do Magnet mais lentas. Fragmentos maiores reduzem o tamanho dos metadados, mas tornam o reparo após um fragmento com falha mais grosseiro.
Por que dois fluxos de dados idênticos acabam em enxames separados, e como posso evitar isso?
Porque o info-hash abrange todo o dicionário de informações. Nomes diferentes, ordem dos arquivos, tamanhos dos fragmentos, flags privadas ou tags de origem produzem hashes diferentes, mesmo para payloads idênticos em bytes. Para manter um único enxame, padronize o tamanho dos fragmentos, o nome, a ordem dos arquivos e as flags no seu processo de lançamento e publique o info-hash junto com o artefato. As tags de origem são uma maneira intencional de separar enxames, e a opção -s do mktorrent altera o hash deliberadamente.
Quais são as principais preocupações de segurança ao escrever um cliente ou analisador sintático para esses formatos?
Trate todas as entradas como não confiáveis. Valide rigorosamente o código de acesso (bencode), limite o tamanho dos metadados (um cliente de código aberto impõe um limite de 32 MB) e remova os caminhos de arquivo dos metadados para evitar a travessia de diretórios. Filtre os endereços privados e de loopback retornados pelos rastreadores e pela DHT para limitar o abuso do tipo SSRF e verifique se os URLs dos rastreadores são aceitáveis antes de conectar. Trate o nome de domínio (dn) como texto não confiável e verifique o hash de cada fragmento antes de gravá-lo no armazenamento final.
Como faço para calcular corretamente um info-hash a partir de um arquivo .torrent?
Localize o intervalo de bytes exato do valor de informação conforme aparece no arquivo e calcule o hash desses bytes: SHA-1 para v1 ou SHA-256 para v2. O BEP 3 enfatiza que o hash é calculado sobre a codificação encontrada no arquivo. Decodificar e recodificar o dicionário só é seguro se o decodificador validar completamente a entrada, e um decodificador permissivo pode normalizar os dados silenciosamente e gerar um hash diferente. Para torrents híbridos, calcule ambos os hashes a partir do mesmo intervalo.
Posso usar um link magnético para um torrent de um rastreador privado?
Muitas vezes não é prático. O BEP 27 exige que os clientes anunciem apenas para o rastreador privado e se conectem apenas aos pares que ele retorna. Um link magnet simples não contém o indicador de privacidade, já que este reside nos metadados, e pode não incluir uma URL de rastreador utilizável. Se uma URL de rastreador com credenciais estiver incorporada, trate o link como um segredo. Esta é a minha inferência a partir da especificação, pois o BEP 27 não aborda links magnet diretamente, portanto, teste com as regras do seu rastreador.
Para distribuir software, conjuntos de dados ou arquivos em um pipeline, devo publicar um link .torrent ou um link magnet?
Publique ambos, com o arquivo .torrent como o artefato canônico. Isso preserva os metadados completos, permite que os usuários inspecionem a lista de arquivos offline e oferece suporte a web seeds (BEP 19) para garantir a disponibilidade. Para maior conveniência, derive o link magnético do mesmo info-hash e publique o info-hash juntamente com um checksum assinado em um canal confiável. Isso proporciona durabilidade ao arquivo e facilita o compartilhamento, sem tornar a recuperação de metadados dependente de outros usuários.
O que determina por quanto tempo um torrent permanece recuperável e como posso melhorar isso?
A recuperabilidade requer pelo menos um nó acessível que contenha os dados e, no caso de links magnéticos, um nó que também contenha os metadados. Melhore isso mantendo os seeders ativos, adicionando múltiplos trackers em camadas (BEP 12) como backup, adicionando web seeds HTTP e mantendo o arquivo .torrent arquivado ou exportável por clientes que armazenam em cache os metadados obtidos. Um link magnético por si só não preserva nada, portanto, um enxame inativo o torna inútil.
Lista ampliada de leituras e tópicos relacionados
- Codificação de dados: O formato de serialização usado pelos arquivos .torrent, com chaves de dicionário ordenadas.
- Info-hash: Digest SHA-1 (v1) ou SHA-256 (v2) do dicionário de informações bencoded, a identidade do torrent
- Armazenamento endereçável por conteúdo: Identificar dados pelo seu hash em vez da sua localização.
- Árvores Merkle: Árvores de hash por arquivo no BitTorrent v2 (BEP 52) para verificação em nível de fragmento.
- Torrents híbridos: torrents únicos contendo estruturas v1 e v2 e dois info-hashes
- Comprimento e número de camadas da peça: a relação de compromisso entre o tamanho dos metadados e a granularidade da verificação
- Resistência a colisões SHA-1: Por que o hash v1 é teoricamente mais fraco e o v2 passa a usar SHA-256?
- Protocolo de extensão (BEP 10): o mecanismo de handshake que permite ut_metadata, PEX e outras extensões
- Troca de metadados (BEP 9, ut_metadata): Obtendo o dicionário de informações dos pares em blocos de 16 KiB
- Esquema de URI Magnet: Um esquema de identificação baseado em hash, independente de projeto, com registro provisório na IANA.
- MAGMA (manifesto magnético): o conceito de tópico manifesto a partir das origens de múltiplas redes do esquema magnet
- Seleção de arquivos Magnet (BEP 53): escolher arquivos específicos dentro de um torrent a partir do próprio link
- Metadados de rastreamento múltiplo (BEP 12): Níveis de lista de anúncios com embaralhamento e failover
- UDP protocolo de rastreamento (BEP 15): Rastreador leve anuncia via UDP
- Listas compactas de pares (BEP 23): a codificação binária compacta de pares em respostas de rastreadores
- Extensão de rastreamento IPv6 (BEP 7): O peers6 anuncia suporte para IPv6.
- Relatórios de IP externo do rastreador (BEP 24): rastreadores informando aos clientes o endereço observado
- DHT de linha principal (BEP 5): Tabela hash distribuída baseada em Kademlia para descoberta de pares sem rastreadores
- Extensão de segurança DHT (BEP 42): restringir IDs de nós para resistir a ataques Sybil e de tabela de roteamento
- DHT put/get e indexação infohash (BEP 44, BEP 51): Armazenar dados e amostrar info-hashes no DHT.
- Troca ponto a ponto, PEX (BEP 11): membros do enxame compartilhando listas de pares diretamente
- Descoberta de serviços locais (BEP 14): Encontrar pares no mesmo segmento de rede
- Extensão Rápida (BEP 6): Atalhos de protocolo como ter tudo, não ter nada e rejeitar
- uTP (BEP 29): um transporte baseado em UDP com controle de congestionamento baseado em atraso
- Extensão para perfurador de furos (BEP 55): A travessia NAT é coordenada por meio de pares de retransmissão.
- Criptografia de fluxo de mensagens (MSE/PE): Ocultação de protocolo, não anonimato.
- Torrents privados (BEP 27): a flag privada que restringe a descoberta de pares ao rastreador
- Web seeding (BEP 17, BEP 19): Servidores HTTP ou FTP atuando como seeds permanentes
- Arquivos de preenchimento (BEP 47): Alinhamento de arquivos aos limites das peças para deduplicação e suporte híbrido.
- Dicas de dados locais (BEP 38): reutilizar dados de torrents relacionados para evitar baixar novamente
- Assinatura de torrent (BEP 35): Assinaturas RSA incorporadas com certificados X.509 opcionais.
- Feeds de atualização de torrents (BEP 39): URL de atualização para torrents sucessores automáticos assinados
- Pipeline de verificação de peças: Verificação de hash antes do commit e recuperação de partes com falha
- Reforço da segurança do analisador sintático e do cliente: código benfeito estrito validação, limites de tamanho, higienização de caminho, filtragem SSRF
- WebTorrent e WebRTC: pares baseados em navegador usando rastreadores ws/wss e ICE ou TURN
- Caixas de sementes e semeadura a longo prazo: Infraestrutura para disponibilidade e persistência de arquivamento
- Processo e governança do BEP: Como as especificações são propostas, indexadas e promovidas da versão Aceita para a versão Final.
- Sistemas alternativos de endereçamento de conteúdo: Identificadores de conteúdo no estilo IPFS como um modelo comparável
- Proveniência versus integridade: Por que os hashes verificam os dados, mas nunca autenticam o editor?
Links externos no Torrent
(Passe o cursor sobre o link para ver nossa descrição do conteúdo)
