NOTA: Este documento foi originalmente escrito por jrandom em 2003. Embora nos esforcemos para mantê-lo atualizado, algumas informações podem estar obsoletas ou incompletas. As seções de transporte e criptografia estão atualizadas em janeiro de 2025.
Introdução
I2P é uma camada de rede anônima escalável, auto-organizável e resiliente com comutação de pacotes, sobre a qual qualquer número de aplicações diferentes com consciência de anonimato ou segurança pode operar. Cada uma dessas aplicações pode fazer seus próprios compromissos entre anonimato, latência e throughput sem se preocupar com a implementação adequada de uma mixnet de rota livre, permitindo que elas misturem sua atividade com o conjunto maior de anonimato de usuários já executando sobre I2P.
As aplicações já disponíveis fornecem toda a gama de atividades típicas da Internet — navegação web anônima, hospedagem web, chat, compartilhamento de arquivos, e-mail, blogging e distribuição de conteúdo, bem como várias outras aplicações em desenvolvimento.
- Navegação web: usando qualquer navegador existente que suporte o uso de um proxy.
- Chat: IRC e outros protocolos
- Compartilhamento de arquivos: I2PSnark e outras aplicações
- E-mail: susimail e outras aplicações
- Blog: usando qualquer servidor web local, ou plugins disponíveis
Ao contrário de sites hospedados em redes de distribuição de conteúdo como Freenet ou GNUnet , os serviços hospedados no I2P são totalmente interativos — existem mecanismos de busca tradicionais estilo web, quadros de avisos, blogs nos quais você pode comentar, sites baseados em banco de dados e pontes para consultar sistemas estáticos como Freenet sem precisar instalá-lo localmente.
Com todas essas aplicações com anonimato habilitado, o I2P assume o papel do middleware orientado a mensagens — as aplicações dizem que querem enviar alguns dados para um identificador criptográfico (um “destination”) e o I2P cuida de garantir que chegue lá de forma segura e anônima. O I2P também inclui uma biblioteca de streaming simples para permitir que as mensagens anônimas de melhor esforço do I2P sejam transferidas como streams confiáveis e ordenados, oferecendo transparentemente um algoritmo de controle de congestionamento baseado em TCP ajustado para o alto produto de largura de banda e atraso da rede. Embora tenham estado disponíveis vários proxies SOCKS simples para conectar aplicações existentes à rede, seu valor tem sido limitado já que quase todas as aplicações rotineiramente expõem o que, num contexto anônimo, são informações sensíveis. A única maneira segura de proceder é auditar completamente uma aplicação para garantir operação adequada e para auxiliar nisso fornecemos uma série de APIs em várias linguagens que podem ser usadas para tirar o máximo proveito da rede.
O I2P não é um projeto de pesquisa — acadêmico, comercial ou governamental — mas sim um esforço de engenharia voltado a fazer o que for necessário para fornecer um nível suficiente de anonimato para aqueles que precisam. Ele está em desenvolvimento ativo desde o início de 2003 com um desenvolvedor em tempo integral e um grupo dedicado de colaboradores em tempo parcial de todo o mundo. Todo o trabalho feito no I2P é código aberto e está livremente disponível no website , com a maioria do código liberada diretamente para o domínio público, embora faça uso de algumas rotinas criptográficas sob licenças estilo BSD. As pessoas que trabalham no I2P não controlam sob quais licenças as pessoas lançam aplicações cliente, e há várias aplicações disponíveis sob GPL (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex e outros). O financiamento para o I2P vem inteiramente de doações, e não recebe benefícios fiscais em nenhuma jurisdição no momento, já que muitos dos desenvolvedores são eles próprios anônimos.
Operação
Visão Geral
Para entender o funcionamento do I2P, é essencial compreender alguns conceitos-chave. Primeiro, o I2P faz uma separação rigorosa entre o software que participa da rede (um “router”) e os pontos finais anônimos (“destinations”) associados a aplicações individuais. O fato de alguém estar executando o I2P geralmente não é segredo. O que é ocultado são informações sobre o que o usuário está fazendo, se é que está fazendo alguma coisa, bem como a que router um destination específico está conectado. Os usuários finais normalmente terão vários destinations locais em seu router — por exemplo, um fazendo proxy para servidores IRC, outro suportando o servidor web anônimo do usuário (“I2P Site”), outro para uma instância I2Phex, outro para torrents, etc.
Outro conceito crítico a ser compreendido é o “tunnel”. Um tunnel é um caminho direcionado através de uma lista explicitamente selecionada de routers. É usada criptografia em camadas, de modo que cada um dos routers só consegue descriptografar uma única camada. A informação descriptografada contém o IP do próximo router, juntamente com a informação criptografada a ser encaminhada. Cada tunnel tem um ponto de partida (o primeiro router, também conhecido como “gateway”) e um ponto final. As mensagens podem ser enviadas apenas numa direção. Para enviar mensagens de volta, é necessário outro tunnel.
Existem dois tipos de tunnels: “tunnels de saída” enviam mensagens para longe do criador do tunnel, enquanto “tunnels de entrada” trazem mensagens para o criador do tunnel. Combinar esses dois tunnels permite que os usuários enviem mensagens uns aos outros. O remetente (“Alice” na imagem acima) configura um tunnel de saída, enquanto o destinatário (“Bob” na imagem acima) cria um tunnel de entrada. O gateway de um tunnel de entrada pode receber mensagens de qualquer outro usuário e irá enviá-las adiante até o endpoint (“Bob”). O endpoint do tunnel de saída precisará enviar a mensagem para o gateway do tunnel de entrada. Para fazer isso, o remetente (“Alice”) adiciona instruções à sua mensagem criptografada. Uma vez que o endpoint do tunnel de saída descriptografa a mensagem, ele terá instruções para encaminhar a mensagem para o gateway de entrada correto (o gateway para “Bob”).
Um terceiro conceito crítico para entender é a “network database” (ou “netDb”) do I2P — um par de algoritmos usados para compartilhar metadados de rede. Os dois tipos de metadados transportados são “routerInfo” e “leaseSets” — o routerInfo fornece aos roteadores os dados necessários para contactar um router específico (suas chaves públicas, endereços de transporte, etc), enquanto o leaseSet fornece aos roteadores as informações necessárias para contactar um destino específico. Um leaseSet contém um número de “leases”. Cada um desses leases especifica um gateway de túnel, que permite alcançar um destino específico. A informação completa contida em um lease:
- Gateway de entrada para um tunnel que permite alcançar um destino específico.
- Momento em que um tunnel expira.
- Par de chaves públicas para poder criptografar mensagens (para enviar através do tunnel e alcançar o destino).
Os routers em si enviam seu routerInfo para o netDb diretamente, enquanto leaseSets são enviados através de tunnels de saída (leaseSets precisam ser enviados anonimamente, para evitar correlacionar um router com seus leaseSets).
Podemos combinar os conceitos acima para construir conexões bem-sucedidas na rede.
Para construir seus próprios tunnels de entrada e saída, Alice faz uma consulta no netDb para coletar routerInfo. Dessa forma, ela reúne listas de peers que pode usar como hops em seus tunnels. Ela pode então enviar uma mensagem de construção para o primeiro hop, solicitando a construção de um tunnel e pedindo que aquele router envie a mensagem de construção adiante, até que o tunnel tenha sido construído.
Quando Alice quer enviar uma mensagem para Bob, ela primeiro faz uma consulta no netDb para encontrar o leaseSet de Bob, obtendo seus gateways de tunnel de entrada atuais. Ela então escolhe um de seus túneis de saída e envia a mensagem através dele com instruções para o endpoint do tunnel de saída encaminhar a mensagem para um dos gateways de tunnel de entrada de Bob. Quando o endpoint do tunnel de saída recebe essas instruções, ele encaminha a mensagem conforme solicitado, e quando o gateway de tunnel de entrada de Bob a recebe, ela é encaminhada através do tunnel para o router de Bob. Se Alice quer que Bob seja capaz de responder à mensagem, ela precisa transmitir seu próprio destino explicitamente como parte da própria mensagem. Isso pode ser feito introduzindo uma camada de nível superior, o que é feito na biblioteca de streaming . Alice também pode reduzir o tempo de resposta incluindo seu LeaseSet mais recente com a mensagem para que Bob não precise fazer uma consulta no netDb quando quiser responder, mas isso é opcional.
Embora os tunnels em si tenham criptografia em camadas para prevenir divulgação não autorizada para pares dentro da rede (assim como a própria camada de transporte faz para prevenir divulgação não autorizada para pares fora da rede), é necessário adicionar uma camada adicional de criptografia ponta a ponta para esconder a mensagem do endpoint do tunnel de saída e do gateway do tunnel de entrada. Esta “garlic encryption ” permite que o router de Alice empacote múltiplas mensagens em uma única “garlic message”, criptografada para uma chave pública específica para que pares intermediários não possam determinar quantas mensagens estão dentro do garlic, o que essas mensagens dizem, ou para onde esses dentes individuais são destinados. Para comunicação típica ponta a ponta entre Alice e Bob, o garlic será criptografado para a chave pública publicada no leaseSet de Bob, permitindo que a mensagem seja criptografada sem divulgar a chave pública para o próprio router de Bob.
Outro fato importante a ter em mente é que o I2P é inteiramente baseado em mensagens e que algumas mensagens podem ser perdidas pelo caminho. Aplicações que usam I2P podem usar as interfaces orientadas a mensagens e cuidar de suas próprias necessidades de controle de congestionamento e confiabilidade, mas a maioria seria melhor atendida reutilizando a biblioteca de streaming fornecida para visualizar o I2P como uma rede baseada em fluxos.
Tunnels
Tanto os tunnels de entrada quanto os de saída funcionam com princípios similares. O gateway do tunnel acumula uma quantidade de mensagens do tunnel, eventualmente pré-processando-as em algo para entrega no tunnel. Em seguida, o gateway criptografa esses dados pré-processados e os encaminha para o primeiro salto. Esse peer e os participantes subsequentes do tunnel adicionam uma camada de criptografia após verificar que não é uma duplicata antes de encaminhar para o próximo peer. Eventualmente, a mensagem chega ao endpoint onde as mensagens são divididas novamente e encaminhadas conforme solicitado. A diferença surge no que o criador do tunnel faz — para tunnels de entrada, o criador é o endpoint e eles simplesmente descriptografam todas as camadas adicionadas, enquanto para tunnels de saída, o criador é o gateway e eles pré-descriptografam todas as camadas para que depois que todas as camadas de criptografia por salto são adicionadas, a mensagem chegue em texto claro no endpoint do tunnel.
A escolha de peers específicos para transmitir mensagens, bem como sua ordenação particular, é importante para compreender tanto as características de anonimato quanto de desempenho do I2P. Enquanto o network database (netDb) tem seus próprios critérios para escolher quais peers consultar e onde armazenar entradas, os criadores de tunnel podem usar quaisquer peers na rede em qualquer ordem (e até mesmo qualquer número de vezes) em um único tunnel. Se dados perfeitos de latência e capacidade fossem conhecidos globalmente, a seleção e ordenação seriam direcionadas pelas necessidades particulares do cliente em conjunto com seu modelo de ameaça. Infelizmente, dados de latência e capacidade não são triviais de coletar anonimamente, e depender de peers não confiáveis para fornecer essas informações tem suas próprias implicações sérias de anonimato.
Do ponto de vista do anonimato, a técnica mais simples seria escolher peers aleatoriamente de toda a rede, ordená-los aleatoriamente e usar esses peers nessa ordem para toda a eternidade. Do ponto de vista do desempenho, a técnica mais simples seria escolher os peers mais rápidos com a capacidade sobressalente necessária, distribuindo a carga entre diferentes peers para lidar com failover transparente, e reconstruir o tunnel sempre que as informações de capacidade mudassem. Embora a primeira seja frágil e ineficiente, a segunda requer informações inacessíveis e oferece anonimato insuficiente. O I2P está trabalhando em oferecer uma gama de estratégias de seleção de peers, juntamente com código de medição consciente do anonimato para organizar os peers por seus perfis.
Como base, o I2P está constantemente criando perfis dos peers com os quais interage, medindo seu comportamento indireto — por exemplo, quando um peer responde a uma consulta netDb em 1,3 segundos, essa latência de ida e volta é registrada nos perfis de todos os routers envolvidos nos dois tunnels (entrada e saída) pelos quais a solicitação e resposta passaram, bem como no perfil do peer consultado. Medição direta, como latência da camada de transporte ou congestionamento, não é usada como parte do perfil, pois pode ser manipulada e associada ao router que está medindo, expondo-o a ataques triviais. Ao coletar esses perfis, uma série de cálculos é executada em cada um para resumir seu desempenho — sua latência, capacidade de lidar com muita atividade, se estão atualmente sobrecarregados e quão bem integrados à rede eles parecem estar. Esses cálculos são então comparados para peers ativos para organizar os routers em quatro níveis — rápido e alta capacidade, alta capacidade, não falhando e falhando. Os limites para esses níveis são determinados dinamicamente, e embora atualmente usem algoritmos bastante simples, existem alternativas.
Usando estes dados de perfil, a estratégia de seleção de peers mais simples e razoável é escolher peers aleatoriamente do nível superior (rápidos e de alta capacidade), e esta está atualmente implementada para tunnels de cliente. Os tunnels exploratórios (usados para netDb e gerenciamento de tunnels) escolhem peers aleatoriamente do nível “não falhando” (que inclui routers em níveis ‘melhores’ também), permitindo que o peer faça amostragem de routers de forma mais ampla, efetivamente otimizando a seleção de peers através de hill climbing randomizado. Estas estratégias sozinhas, no entanto, vazam informações sobre os peers no nível superior do router através de ataques de predecessor e coleta de netDb. Por sua vez, existem várias alternativas que, embora não equilibrem a carga de forma tão uniforme, abordam os ataques montados por classes específicas de adversários.
Ao escolher uma chave aleatória e ordenar os peers de acordo com sua distância XOR dela, a informação vazada é reduzida em ataques de predecessor e harvesting de acordo com a taxa de falha dos peers e a rotatividade da camada. Outra estratégia simples para lidar com ataques de harvesting do netDb é simplesmente fixar o(s) gateway(s) do tunnel de entrada, mas randomizar os peers mais adiante nos tunnels. Para lidar com ataques de predecessor para adversários que o cliente contata, os endpoints do tunnel de saída também permaneceriam fixos. A seleção de qual peer fixar no ponto mais exposto naturalmente precisaria ter um limite de duração, já que todos os peers eventualmente falham, então poderia ser ajustada reativamente ou evitada proativamente para imitar um tempo médio medido entre falhas de outros routers. Essas duas estratégias podem, por sua vez, ser combinadas, usando um peer exposto fixo e uma ordenação baseada em XOR dentro dos próprios tunnels. Uma estratégia mais rígida fixaria os peers exatos e a ordenação de um tunnel potencial, usando peers individuais apenas se todos eles concordarem em participar da mesma forma a cada vez. Isso varia da ordenação baseada em XOR no sentido de que o predecessor e sucessor de cada peer é sempre o mesmo, enquanto o XOR apenas garante que sua ordem não mude.
Como mencionado anteriormente, o I2P atualmente (versão 0.8) inclui a estratégia aleatória em camadas acima, com ordenação baseada em XOR. Uma discussão mais detalhada da mecânica envolvida na operação, gerenciamento e seleção de peers de tunnel pode ser encontrada na especificação de tunnel .
Network Database (netDb)
Como mencionado anteriormente, o netDb do I2P funciona para compartilhar os metadados da rede. Isso é detalhado na página do banco de dados da rede , mas uma explicação básica está disponível abaixo.
Todos os routers I2P contêm um netDb local, mas nem todos os routers participam no DHT ou respondem a consultas de leaseSet. Os routers que participam no DHT e respondem a consultas de leaseSet são chamados ‘floodfills’. Os routers podem ser configurados manualmente como floodfills, ou tornar-se automaticamente floodfill se tiverem capacidade suficiente e cumprirem outros critérios para operação confiável.
Outros routers I2P armazenarão seus dados e buscarão dados enviando consultas simples de ‘store’ e ’lookup’ para os floodfills. Se um router floodfill receber uma consulta ‘store’, ele espalhará a informação para outros routers floodfill usando o algoritmo Kademlia . As consultas ’lookup’ atualmente funcionam de forma diferente, para evitar uma questão de segurança importante. Quando uma busca é feita, o router floodfill não encaminhará a busca para outros peers, mas sempre responderá por si mesmo (se tiver os dados solicitados).
Dois tipos de informação são armazenados na base de dados de rede.
- Um RouterInfo armazena informações sobre um router I2P específico e como contatá-lo
- Um LeaseSet armazena informações sobre um destino específico (ex: site I2P, servidor de e-mail…)
Todas essas informações são assinadas pela parte publicadora e verificadas por qualquer router I2P que utilize ou armazene as informações. Além disso, os dados contêm informações de tempo, para evitar o armazenamento de entradas antigas e possíveis ataques. É por isso que o I2P inclui o código necessário para manter a hora correta, consultando ocasionalmente alguns servidores SNTP (o round robin pool.ntp.org por padrão) e detectando desvios entre routers na camada de transporte.
Algumas observações adicionais também são importantes.
LeaseSets não publicados e criptografados: Alguém pode querer que apenas pessoas específicas consigam alcançar um destino. Isso é possível não publicando o destino no netDb. Você terá, no entanto, que transmitir o destino por outros meios. Isso é suportado por ’leaseSets criptografados’. Esses leaseSets só podem ser decodificados por pessoas com acesso à chave de descriptografia.
Bootstrapping: O bootstrapping da netDb é bastante simples. Uma vez que um router consegue receber um único routerInfo de um peer alcançável, ele pode consultar esse router para obter referências a outros routers na rede. Atualmente, vários usuários publicam seus arquivos routerInfo em um website para disponibilizar essas informações. O I2P conecta-se automaticamente a um desses websites para coletar arquivos routerInfo e fazer o bootstrap. O I2P chama esse processo de bootstrap de “reseeding”.
Escalabilidade de pesquisa: As pesquisas na rede I2P são iterativas, não recursivas. Se uma pesquisa de um floodfill falhar, a pesquisa será repetida para o próximo floodfill mais próximo. O floodfill não pergunta recursivamente a outro floodfill pelos dados. Pesquisas iterativas são escaláveis para grandes redes DHT.
Protocolos de Transporte
A comunicação entre routers precisa fornecer confidencialidade e integridade contra adversários externos, ao mesmo tempo que autentica que o router contatado é aquele que deveria receber uma determinada mensagem. Os detalhes específicos de como os routers se comunicam com outros routers não são críticos — três protocolos separados foram utilizados em diferentes momentos para fornecer essas necessidades básicas.
O I2P atualmente suporta dois protocolos de transporte, NTCP2 sobre TCP, e SSU2 sobre UDP. Estes substituíram as versões anteriores dos protocolos, NTCP e SSU , que agora estão obsoletos. Ambos os protocolos suportam tanto IPv4 quanto IPv6. Ao suportar transportes TCP e UDP, o I2P pode atravessar efetivamente a maioria dos firewalls, incluindo aqueles destinados a bloquear tráfego em regimes de censura restritivos. NTCP2 e SSU2 foram projetados para usar padrões de criptografia modernos, melhorar a resistência à identificação de tráfego, aumentar a eficiência e segurança, e tornar a travessia de NAT mais robusta. Os routers publicam cada transporte suportado e endereço IP no banco de dados da rede. Routers com acesso a redes IPv4 e IPv6 públicas geralmente publicarão quatro endereços, um para cada combinação de NTCP2/SSU2 com IPv4/IPv6.
SSU2 suporta e estende os objetivos do SSU. SSU2 tem muitas semelhanças com outros protocolos modernos baseados em UDP, como Wireguard e QUIC. Além do transporte confiável de mensagens de rede sobre UDP, SSU2 fornece facilidades especializadas para detecção cooperativa de endereços IP peer-to-peer, detecção de firewall e travessia de NAT. Como descrito na especificação SSU :
O objetivo deste protocolo é fornecer entrega de mensagens segura, autenticada, semi-confiável e não ordenada, expondo apenas uma quantidade mínima de dados facilmente discerníveis por terceiros. Deve suportar comunicação de alto grau, bem como controle de congestionamento compatível com TCP e pode incluir detecção PMTU. Deve ser capaz de mover dados em massa de forma eficiente em taxas suficientes para usuários domésticos. Além disso, deve suportar técnicas para contornar obstáculos de rede, como a maioria dos NATs ou firewalls.
NTCP2 suporta e estende os objetivos do NTCP. Ele fornece um transporte eficiente e totalmente criptografado de mensagens de rede sobre TCP, e resistência à identificação de tráfego, usando padrões modernos de criptografia.
I2P suporta múltiplos transportes simultaneamente. Um transporte específico para uma conexão de saída é selecionado com “lances”. Cada transporte faz um lance pela conexão e o valor relativo desses lances atribui a prioridade. Os transportes podem responder com lances diferentes, dependendo de já haver uma conexão estabelecida com o peer.
Os valores de bid (prioridade) dependem da implementação e podem variar com base nas condições de tráfego, contagem de conexões e outros fatores. Os routers também publicam suas preferências de transporte para conexões de entrada na base de dados da rede como “custos” de transporte para cada transporte e endereço.
Criptografia
O I2P usa criptografia em várias camadas de protocolo para criptografia, autenticação e verificação. As principais camadas de protocolo são: transportes, mensagens de construção de tunnel, criptografia de camada de tunnel, mensagens de banco de dados de rede e mensagens ponto a ponto (garlic). O design original do I2P usava um pequeno conjunto de primitivas criptográficas que na época eram consideradas seguras. Isso incluía criptografia assimétrica ElGamal, assinaturas DSA-SHA1, criptografia simétrica AES256/CBC e hashes SHA-256. À medida que o poder computacional disponível aumentou e a pesquisa criptográfica evoluiu substancialmente ao longo dos anos, o I2P precisou atualizar suas primitivas e protocolos. Portanto, adicionamos um conceito de “tipos de criptografia” e “tipos de assinatura”, e estendemos nossos protocolos para incluir esses identificadores e indicar suporte. Isso nos permite atualizar periodicamente e estender o suporte da rede para criptografia moderna e preparar a rede para o futuro com novas primitivas, sem quebrar a compatibilidade com versões anteriores ou exigir um “flag day” para atualizações de rede. Alguns tipos de assinatura e criptografia também são reservados para uso experimental.
As primitivas atuais utilizadas na maioria das camadas de protocolo são troca de chaves X25519, assinaturas EdDSA, criptografia simétrica autenticada ChaCha20/Poly1305 e hashes SHA-256. AES256 ainda é usado para criptografia da camada de tunnel. Esses protocolos modernos são utilizados para a grande maioria da comunicação de rede. Primitivas mais antigas incluindo ElGamal, ECDSA e DSA-SHA1 continuam sendo suportadas pela maioria das implementações para compatibilidade com versões anteriores ao comunicar com routers mais antigos. Alguns protocolos antigos foram descontinuados e/ou removidos completamente. No futuro próximo começaremos a pesquisa sobre uma migração para criptografia e assinaturas pós-quânticas (PQ) ou PQ híbridas para manter nossos padrões robustos de segurança.
Essas primitivas criptográficas são combinadas para fornecer as defesas em camadas do I2P contra uma variedade de adversários. No nível mais baixo, a comunicação entre routers é protegida pela segurança da camada de transporte. Mensagens de tunnel passadas pelos transportes têm sua própria criptografia em camadas. Várias outras mensagens são passadas dentro de “garlic messages”, que também são criptografadas.
Mensagens Garlic
As mensagens garlic são uma extensão da criptografia em camadas tipo “cebola”, permitindo que o conteúdo de uma única mensagem contenha múltiplos “cravos” — mensagens totalmente formadas junto com suas próprias instruções de entrega. As mensagens são encapsuladas em uma mensagem garlic sempre que a mensagem passaria em texto simples através de um peer que não deveria ter acesso à informação — por exemplo, quando um router quer pedir a outro router para participar em um tunnel, eles encapsulam a solicitação dentro de um garlic, criptografam esse garlic com a chave pública do router receptor, e o encaminham através de um tunnel. Outro exemplo é quando um cliente quer enviar uma mensagem para um destino — o router do remetente irá encapsular essa mensagem de dados (junto com algumas outras mensagens) em um garlic, criptografar esse garlic com a chave pública publicada no leaseSet do destinatário, e encaminhá-lo através dos tunnels apropriados.
As “instruções” anexadas a cada clove dentro da camada de criptografia incluem a capacidade de solicitar que o clove seja encaminhado localmente, para um router remoto, ou para um tunnel remoto em um router remoto. Há campos nessas instruções que permitem a um peer solicitar que a entrega seja atrasada até que um determinado tempo ou condição seja atendida, embora não sejam honrados até que os atrasos não triviais sejam implementados. É possível rotear explicitamente mensagens garlic encryption por qualquer número de saltos sem construir tunnels, ou até mesmo rerotear mensagens de tunnel envolvendo-as em mensagens garlic encryption e encaminhando-as por alguns saltos antes de entregá-las ao próximo salto no tunnel, mas essas técnicas não são utilizadas atualmente na implementação existente.
Tags de Sessão
Como um sistema não confiável, desordenado e baseado em mensagens, o I2P usa uma combinação simples de algoritmos de criptografia assimétrica e simétrica para fornecer confidencialidade e integridade dos dados para garlic messages. A combinação original era referida como ElGamal/AES+SessionTags, mas essa é uma maneira excessivamente verbosa de descrever o uso simples de ElGamal 2048bit, AES256, SHA256 e nonces de 32 bytes. Embora este protocolo ainda seja suportado, a maior parte da rede migrou para um novo protocolo, ECIES-X25519-AEAD-Ratchet. Este protocolo combina X25519, ChaCha20/Poly1305 e um PRNG sincronizado para gerar os nonces de 32 bytes. Ambos os protocolos serão brevemente descritos abaixo.
ElGamal/AES+SessionTags
A primeira vez que um router quer criptografar uma mensagem garlic para outro router, eles criptografam o material de chaveamento para uma chave de sessão AES256 com ElGamal e anexam o payload criptografado AES256/CBC após esse bloco ElGamal criptografado. Além do payload criptografado, a seção criptografada AES contém o comprimento do payload, o hash SHA256 do payload não criptografado, bem como um número de “session tags” — nonces aleatórios de 32 bytes. Na próxima vez que o remetente quiser criptografar uma mensagem garlic para outro router, em vez de criptografar com ElGamal uma nova chave de sessão, eles simplesmente escolhem uma das session tags entregues anteriormente e criptografam o payload com AES como antes, usando a chave de sessão usada com essa session tag, precedida pela própria session tag. Quando um router recebe uma mensagem criptografada garlic, eles verificam os primeiros 32 bytes para ver se corresponde a uma session tag disponível — se corresponder, eles simplesmente descriptografam a mensagem com AES, mas se não corresponder, eles descriptografam o primeiro bloco com ElGamal.
Cada tag de sessão pode ser usada apenas uma vez para evitar que adversários internos correlacionem desnecessariamente mensagens diferentes como sendo entre os mesmos routers. O remetente de uma mensagem criptografada ElGamal/AES+SessionTag escolhe quando e quantas tags entregar, abastecendo previamente o destinatário com tags suficientes para cobrir uma sequência de mensagens. Mensagens garlic podem detectar a entrega bem-sucedida de tags agrupando uma pequena mensagem adicional como um dente (uma “mensagem de status de entrega”) — quando a mensagem garlic chega ao destinatário pretendido e é descriptografada com sucesso, essa pequena mensagem de status de entrega é um dos dentes expostos e possui instruções para o destinatário enviar o dente de volta ao remetente original (através de um tunnel de entrada, claro). Quando o remetente original recebe essa mensagem de status de entrega, ele sabe que as tags de sessão agrupadas na mensagem garlic foram entregues com sucesso.
Os session tags em si têm um tempo de vida muito curto, após o qual são descartados se não forem usados. Além disso, a quantidade armazenada para cada chave é limitada, assim como o número das próprias chaves — se muitas chegarem, mensagens novas ou antigas podem ser descartadas. O remetente acompanha se as mensagens usando session tags estão passando, e se não houver comunicação suficiente, pode descartar aquelas anteriormente assumidas como entregues adequadamente, revertendo de volta para a criptografia ElGamal completa e custosa.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags exigia overhead substancial de várias maneiras. O uso de CPU era alto porque ElGamal é bastante lento. A largura de banda era excessiva porque grandes números de session tags tinham que ser entregues antecipadamente, e porque as chaves públicas ElGamal são muito grandes. O uso de memória era alto devido à necessidade de armazenar grandes quantidades de session tags. A confiabilidade era prejudicada pela perda na entrega de session tags.
ECIES-X25519-AEAD-Ratchet foi projetado para resolver esses problemas. X25519 é usado para troca de chaves. ChaCha20/Poly1305 é usado para criptografia simétrica autenticada. As chaves de criptografia são “duplo ratcheted” ou rotacionadas periodicamente. As tags de sessão são reduzidas de 32 bytes para 8 bytes e são geradas com um PRNG. O protocolo tem muitas semelhanças com o protocolo signal usado no Signal e WhatsApp. Este protocolo oferece substancialmente menor sobrecarga em CPU, RAM e largura de banda.
As session tags são geradas a partir de um PRNG determinístico sincronizado executando em ambas as extremidades da sessão para gerar session tags e chaves de sessão. O PRNG é um HKDF usando um SHA-256 HMAC, e é semeado a partir do resultado X25519 DH. Session tags nunca são transmitidas antecipadamente; elas são incluídas apenas com a mensagem. O receptor armazena um número limitado de chaves de sessão, indexadas por session tag. O remetente não precisa armazenar nenhuma session tag ou chave porque elas não são enviadas antecipadamente; elas podem ser geradas sob demanda. Ao manter este PRNG aproximadamente sincronizado entre o remetente e o destinatário (o destinatário pré-calcula uma janela das próximas 50 tags, por exemplo), a sobrecarga de periodicamente agrupar um grande número de tags é removida.
Futuro
Os protocolos do I2P são eficientes na maioria das plataformas, incluindo celulares, e seguros para a maioria dos modelos de ameaça. No entanto, existem várias áreas que requerem melhorias adicionais para atender às necessidades daqueles que enfrentam adversários poderosos patrocinados pelo Estado, e para enfrentar as ameaças dos avanços criptográficos contínuos e do poder computacional sempre crescente. Duas características possíveis, rotas restritas e latência variável, foram propostas por jrandom em 2003. Embora não planejemos mais implementar essas características, elas são descritas abaixo.
Operação de Rota Restrita
I2P é uma rede sobreposta projetada para funcionar sobre uma rede funcional de comutação de pacotes, explorando o princípio fim a fim para oferecer anonimato e segurança. Embora a Internet não abranja mais completamente o princípio fim a fim (devido ao uso de NAT), I2P requer que uma porção substancial da rede seja alcançável — pode haver vários peers nas bordas executando usando rotas restritas, mas I2P não inclui um algoritmo de roteamento apropriado para o caso degenerativo onde a maioria dos peers são inalcançáveis. No entanto, funcionaria sobre uma rede que emprega tal algoritmo.
A operação de rota restrita, onde há limitações sobre quais peers são acessíveis diretamente, possui várias implicações funcionais e de anonimato diferentes, dependendo de como as rotas restritas são tratadas. No nível mais básico, rotas restritas existem quando um peer está atrás de um NAT ou firewall que não permite conexões de entrada. Isso foi amplamente resolvido através da integração de perfuração distribuída de buracos na camada de transporte, permitindo que pessoas atrás da maioria dos NATs e firewalls recebam conexões não solicitadas sem qualquer configuração. No entanto, isso não limita a exposição do endereço IP do peer aos routers dentro da rede, pois eles podem simplesmente ser apresentados ao peer através do introducer publicado.
Além do tratamento funcional de rotas restritas, existem dois níveis de operação restrita que podem ser usados para limitar a exposição do endereço IP — usando tunnels específicos do router para comunicação e oferecendo ‘client routers’. Para o primeiro caso, os routers podem construir um novo pool de tunnels ou reutilizar seu pool exploratório, publicando os gateways de entrada para alguns deles como parte de seu routerInfo no lugar de seus endereços de transporte. Quando um peer quer entrar em contato com eles, vê esses gateways de tunnel no netDb e simplesmente envia a mensagem relevante através de um dos tunnels publicados. Se o peer por trás da rota restrita quiser responder, pode fazê-lo diretamente (se estiver disposto a expor seu IP ao peer) ou indiretamente através de seus tunnels de saída. Quando os routers aos quais o peer tem conexões diretas querem alcançá-lo (para encaminhar mensagens de tunnel, por exemplo), eles simplesmente priorizam sua conexão direta sobre o gateway de tunnel publicado. O conceito de ‘client routers’ simplesmente estende a rota restrita ao não publicar nenhum endereço de router. Tal router nem precisaria publicar seu routerInfo no netDb, apenas fornecendo seu routerInfo autoassinado aos peers que contata (necessário para passar as chaves públicas do router).
Existem compensações para aqueles que estão atrás de rotas restritas, pois eles provavelmente participariam dos túneis de outras pessoas com menos frequência, e os routers aos quais estão conectados seriam capazes de inferir padrões de tráfego que de outra forma não estariam expostos. Por outro lado, se o custo dessa exposição for menor que o custo de disponibilizar um IP, pode valer a pena. Isso, é claro, assume que os peers que o router atrás de uma rota restrita contata não são hostis — seja porque a rede é grande o suficiente para que a probabilidade de usar um peer hostil para se conectar seja pequena o suficiente, ou peers confiáveis (e talvez temporários) sejam usados em vez disso.
As rotas restritas são complexas, e o objetivo geral foi amplamente abandonado. Várias melhorias relacionadas reduziram drasticamente a necessidade delas. Agora suportamos UPnP para abrir automaticamente as portas do firewall. Suportamos tanto IPv4 quanto IPv6. O SSU2 melhorou a detecção de endereços, determinação do estado do firewall e perfuração cooperativa de NAT. SSU2, NTCP2 e verificações de compatibilidade de endereços garantem que os saltos de tunnel possam se conectar antes que o tunnel seja construído. GeoIP e identificação de país nos permitem evitar peers em países com firewalls restritivos. O suporte para routers “ocultos” por trás desses firewalls melhorou. Algumas implementações também suportam conexões com peers em redes overlay como Yggdrasil.
Latência Variável
Embora a maior parte dos esforços iniciais do I2P tenham se concentrado na comunicação de baixa latência, foi projetado desde o início com serviços de latência variável em mente. No nível mais básico, aplicações executadas sobre o I2P podem oferecer o anonimato da comunicação de média e alta latência enquanto ainda misturam seus padrões de tráfego com o tráfego de baixa latência. Internamente, porém, o I2P pode oferecer sua própria comunicação de média e alta latência através da garlic encryption — especificando que a mensagem deve ser enviada após um certo atraso, em um determinado momento, depois que um certo número de mensagens tenha passado, ou outra estratégia de mistura. Com a criptografia em camadas, apenas o router que o clove expôs à solicitação de atraso saberia que a mensagem requer alta latência, permitindo que o tráfego se misture ainda mais com o tráfego de baixa latência. Uma vez que a pré-condição de transmissão é atendida, o router que retém o clove (que por si só provavelmente seria uma mensagem garlic) simplesmente o encaminha conforme solicitado — para um router, para um tunnel, ou, mais provavelmente, para um destino de cliente remoto.
O objetivo dos serviços de latência variável requer recursos substanciais para mecanismos de store-and-forward para suportá-lo. Esses mecanismos podem e são suportados em várias aplicações de mensagens, como o i2p-bote. No nível de rede, redes alternativas como Freenet fornecem esses serviços. Decidimos não perseguir esse objetivo no nível do router I2P.
Sistemas Similares
A arquitetura do I2P baseia-se nos conceitos de middleware orientado a mensagens, na topologia de DHTs, no anonimato e criptografia de mixnets de rota livre, e na adaptabilidade de redes de comutação de pacotes. O valor não vem de conceitos ou algoritmos inovadores, mas da engenharia cuidadosa que combina os resultados de pesquisa de sistemas e artigos existentes. Embora existam alguns esforços similares que vale a pena revisar, tanto para comparações técnicas quanto funcionais, dois em particular são destacados aqui — Tor e Freenet.
Veja também a Página de Comparações de Rede . Note que essas descrições foram escritas por jrandom em 2003 e podem não ser precisas atualmente.
Tor
À primeira vista, Tor e I2P têm muitas semelhanças funcionais e relacionadas ao anonimato. Embora o desenvolvimento do I2P tenha começado antes de estarmos cientes dos esforços iniciais do Tor, muitas das lições do onion routing original e dos esforços ZKS foram integradas ao design do I2P. Em vez de construir um sistema essencialmente confiável e centralizado com servidores de diretório, o I2P possui uma base de dados de rede auto-organizável com cada peer assumindo a responsabilidade de criar perfis de outros routers para determinar a melhor forma de explorar os recursos disponíveis. Outra diferença importante é que, embora tanto o I2P quanto o Tor usem caminhos em camadas e ordenados (tunnels e circuits/streams), o I2P é fundamentalmente uma rede comutada por pacotes, enquanto o Tor é fundamentalmente uma rede comutada por circuitos, permitindo ao I2P rotear transparentemente em torno de congestionamentos ou outras falhas de rede, operar caminhos redundantes e equilibrar a carga dos dados através dos recursos disponíveis. Enquanto o Tor oferece a funcionalidade útil de outproxy ao fornecer descoberta e seleção integrada de outproxy, o I2P deixa tais decisões da camada de aplicação para as aplicações executadas sobre o I2P — de fato, o I2P externalizou até mesmo a própria biblioteca de streaming semelhante ao TCP para a camada de aplicação, permitindo que os desenvolvedores experimentem com diferentes estratégias, explorando seu conhecimento específico do domínio para oferecer melhor desempenho.
Do ponto de vista do anonimato, há muita semelhança quando as redes principais são comparadas. No entanto, existem algumas diferenças fundamentais. Ao lidar com um adversário interno ou a maioria dos adversários externos, os tunnels simplex do I2P expõem metade dos dados de tráfego que seriam expostos com os circuitos duplex do Tor, simplesmente observando os fluxos em si — uma requisição e resposta HTTP seguiriam o mesmo caminho no Tor, enquanto no I2P os pacotes que compõem a requisição sairiam através de um ou mais tunnels de saída e os pacotes que compõem a resposta voltariam através de um ou mais tunnels de entrada diferentes. Embora as estratégias de seleção e ordenação de pares do I2P devam abordar adequadamente os ataques predecessores, caso uma mudança para tunnels bidirecionais seja necessária, poderíamos simplesmente construir um tunnel de entrada e saída ao longo dos mesmos routers.
Outra questão de anonimato surge no uso do Tor da criação telescópica de tunnel, já que a simples contagem de pacotes e medições de tempo conforme as células em um circuito passam através do nó de um adversário expõe informações estatísticas sobre onde o adversário está dentro do circuito. A criação unidirecional de tunnel do I2P usa uma única mensagem para que esses dados não sejam expostos. Proteger a posição em um tunnel é importante, pois de outra forma um adversário seria capaz de montar uma série de poderosos ataques de predecessor, interseção e confirmação de tráfego.
No geral, Tor e I2P se complementam em seu foco — Tor trabalha para oferecer proxy de saída anônimo de alta velocidade para a Internet, enquanto I2P trabalha para oferecer uma rede resiliente descentralizada em si. Em teoria, ambos podem ser usados para alcançar ambos os propósitos, mas dados os recursos de desenvolvimento limitados, ambos têm suas forças e fraquezas. Os desenvolvedores do I2P consideraram os passos necessários para modificar o Tor para aproveitar o design do I2P, mas preocupações sobre a viabilidade do Tor sob escassez de recursos sugerem que a arquitetura de comutação de pacotes do I2P será capaz de explorar recursos escassos de forma mais eficaz.
Freenet
Freenet desempenhou um papel importante nos estágios iniciais do design do I2P — fornecendo prova da viabilidade de uma comunidade pseudônima vibrante completamente contida dentro da rede, demonstrando que os perigos inerentes aos outproxies poderiam ser evitados. A primeira semente do I2P começou como uma camada de comunicação substituta para Freenet, tentando separar as complexidades de uma comunicação ponto a ponto escalável, anônima e segura das complexidades de um armazenamento de dados distribuído resistente à censura. Com o tempo, no entanto, algumas das questões de anonimato e escalabilidade inerentes aos algoritmos do Freenet deixaram claro que o foco do I2P deveria permanecer estritamente em fornecer uma camada de comunicação anônima genérica, em vez de ser um componente do Freenet. Ao longo dos anos, os desenvolvedores do Freenet passaram a ver as fraquezas no design mais antigo, levando-os a sugerir que eles precisarão de uma camada “premix” para oferecer anonimato substancial. Em outras palavras, Freenet precisa rodar sobre uma mixnet como I2P ou Tor, com “nós cliente” solicitando e publicando dados através da mixnet para os “nós servidor” que então buscam e armazenam os dados de acordo com os algoritmos heurísticos de armazenamento de dados distribuídos do Freenet.
A funcionalidade do Freenet é muito complementar à do I2P, pois o Freenet fornece nativamente muitas das ferramentas para operar sistemas de média e alta latência, enquanto o I2P fornece nativamente a rede de mistura de baixa latência adequada para oferecer anonimato apropriado. A lógica de separar a mixnet do armazenamento de dados distribuído resistente à censura ainda parece evidente do ponto de vista de engenharia, anonimato, segurança e alocação de recursos, então espera-se que a equipe do Freenet persiga esforços nessa direção, se não simplesmente reutilizando (ou ajudando a melhorar, conforme necessário) mixnets existentes como I2P ou Tor.
Apêndice A: Camada de Aplicação
O próprio I2P não faz muito — ele simplesmente envia mensagens para destinos remotos e recebe mensagens direcionadas a destinos locais — a maior parte do trabalho interessante acontece nas camadas acima dele. Por si só, o I2P pode ser visto como uma camada IP anônima e segura, e a biblioteca de streaming incluída como uma implementação de uma camada TCP anônima e segura sobre ela. Além disso, o I2PTunnel expõe um sistema genérico de proxy TCP para entrar ou sair da rede I2P, além de uma variedade de aplicações de rede que fornecem funcionalidade adicional para os usuários finais.
Biblioteca de Streaming
A biblioteca de streaming I2P pode ser vista como uma interface de streaming genérica (espelhando sockets TCP), e a implementação suporta um protocolo de janela deslizante com várias otimizações, para levar em conta o alto delay sobre I2P. Streams individuais podem ajustar o tamanho máximo de pacote e outras opções, embora o padrão de 4KB comprimido pareça um equilíbrio razoável entre os custos de largura de banda de retransmitir mensagens perdidas e a latência de múltiplas mensagens.
Além disso, considerando o custo relativamente alto das mensagens subsequentes, o protocolo da biblioteca de streaming para agendamento e entrega de mensagens foi otimizado para permitir que mensagens individuais passadas contenham o máximo de informação disponível. Por exemplo, uma pequena transação HTTP proxificada através da biblioteca de streaming pode ser concluída em uma única ida e volta — a primeira mensagem agrupa um SYN, FIN e a pequena carga útil (uma requisição HTTP normalmente cabe) e a resposta agrupa o SYN, FIN, ACK e a pequena carga útil (muitas respostas HTTP cabem). Embora um ACK adicional deva ser transmitido para informar ao servidor HTTP que o SYN/FIN/ACK foi recebido, o proxy HTTP local pode entregar a resposta completa ao navegador imediatamente.
No geral, entretanto, a biblioteca de streaming tem muita semelhança com uma abstração do TCP, com suas janelas deslizantes, algoritmos de controle de congestionamento (tanto slow start quanto prevenção de congestionamento), e comportamento geral de pacotes (ACK, SYN, FIN, RST, etc).
Biblioteca de Nomeação e Livro de Endereços
Para mais informações, consulte a página Naming and Address Book .
Desenvolvido por: mihi, Ragnarok
A nomenclatura dentro do I2P tem sido um tópico muito debatido desde o início, com defensores em todo o espectro de possibilidades. No entanto, dada a demanda inerente do I2P por comunicação segura e operação descentralizada, o sistema de nomenclatura tradicional estilo DNS está claramente fora de questão, assim como sistemas de votação de “regra da maioria”. Em vez disso, o I2P vem com uma biblioteca de nomenclatura genérica e uma implementação base projetada para funcionar com um mapeamento local de nome para destination, bem como uma aplicação adicional opcional chamada “Address Book”. O address book é um sistema de nomenclatura seguro, distribuído e legível por humanos baseado em web-of-trust, sacrificando apenas a exigência de que todos os nomes legíveis por humanos sejam globalmente únicos ao exigir apenas unicidade local. Embora todas as mensagens no I2P sejam criptograficamente endereçadas por seu destination, pessoas diferentes podem ter entradas locais no address book para “Alice” que se referem a destinations diferentes. As pessoas ainda podem descobrir novos nomes importando address books publicados de pares especificados em sua web of trust, adicionando as entradas fornecidas através de terceiros, ou (se algumas pessoas organizarem uma série de address books publicados usando um sistema de registro por ordem de chegada) as pessoas podem escolher tratar esses address books como servidores de nomes, emulando o DNS tradicional.
O I2P não promove o uso de serviços semelhantes ao DNS, pois os danos causados pelo sequestro de um site podem ser tremendos — e destinos inseguros não têm valor. O próprio DNSsec ainda depende de registradores e autoridades certificadoras, enquanto com o I2P, solicitações enviadas a um destino não podem ser interceptadas ou a resposta falsificada, pois são criptografadas para as chaves públicas do destino, e um destino em si é apenas um par de chaves públicas e um certificado. Sistemas estilo DNS, por outro lado, permitem que qualquer um dos servidores de nomes no caminho de consulta monte ataques simples de negação de serviço e falsificação. Adicionar um certificado autenticando as respostas como assinadas por alguma autoridade certificadora centralizada resolveria muitos dos problemas de servidores de nomes hostis, mas deixaria abertos ataques de replay bem como ataques de autoridades certificadoras hostis.
A nomenclatura por estilo de votação também é perigosa, especialmente considerando a eficácia dos ataques Sybil em sistemas anônimos — o atacante pode simplesmente criar um número arbitrariamente alto de peers e “votar” com cada um para tomar controle de um determinado nome. Métodos de proof-of-work podem ser usados para tornar a identidade não-gratuita, mas conforme a rede cresce, a carga necessária para contactar todos para conduzir votação online torna-se implausível, ou se a rede completa não for consultada, diferentes conjuntos de respostas podem ser alcançáveis.
Assim como na Internet, no entanto, o I2P mantém o design e operação de um sistema de nomenclatura fora da camada de comunicação (similar ao IP). A biblioteca de nomenclatura incluída possui uma interface de provedor de serviços simples na qual sistemas de nomenclatura alternativos podem se conectar, permitindo que os usuários finais escolham que tipo de compromissos de nomenclatura preferem.
I2PTunnel
Desenvolvido por: mihi
I2PTunnel é provavelmente a aplicação cliente mais popular e versátil do I2P, permitindo proxy genérico tanto para dentro quanto para fora da rede I2P. I2PTunnel pode ser visto como quatro aplicações de proxy separadas — um “client” que recebe conexões TCP de entrada e as encaminha para um destino I2P específico, um “httpclient” (também conhecido como “eepproxy”) que atua como um proxy HTTP e encaminha as requisições para o destino I2P apropriado (após consultar o serviço de nomes, se necessário), um “server” que recebe conexões de streaming I2P de entrada em um destino e as encaminha para um host+porta TCP específico, e um “httpserver” que estende o “server” analisando as requisições e respostas HTTP para permitir operação mais segura. Há uma aplicação adicional “socksclient”, mas seu uso não é encorajado pelos motivos mencionados anteriormente.
O I2P em si não é uma rede de outproxy — as preocupações de anonimato e segurança inerentes a uma rede de mistura que encaminha dados para dentro e para fora da mistura mantiveram o design do I2P focado em fornecer uma rede anônima capaz de atender às necessidades do usuário sem exigir recursos externos. No entanto, a aplicação “httpclient” do I2PTunnel oferece um gancho para outproxying — se o nome do host solicitado não terminar em “.i2p”, ele escolhe um destino aleatório de um conjunto de outproxies fornecido pelo usuário e encaminha a solicitação para eles. Esses destinos são simplesmente instâncias de “server” do I2PTunnel executadas por voluntários que escolheram explicitamente executar outproxies — ninguém é um outproxy por padrão, e executar um outproxy não diz automaticamente a outras pessoas para fazer proxy através de você. Embora os outproxies tenham fraquezas inerentes, eles oferecem uma prova de conceito simples para usar o I2P e fornecem alguma funcionalidade sob um modelo de ameaça que pode ser suficiente para alguns usuários.
O I2PTunnel habilita a maioria das aplicações em uso. Um “httpserver” apontando para um servidor web permite que qualquer pessoa execute seu próprio website anônimo (ou “I2P Site”) — um servidor web é incluído com o I2P para este propósito, mas qualquer servidor web pode ser usado. Qualquer pessoa pode executar um “client” apontando para um dos servidores IRC hospedados anonimamente, cada um dos quais está executando um “server” apontando para seu IRCd local e se comunicando entre IRCds através de seus próprios tunnels “client”. Os usuários finais também têm tunnels “client” apontando para os destinos POP3 e SMTP do I2Pmail (que por sua vez são simplesmente instâncias “server” apontando para servidores POP3 e SMTP), bem como tunnels “client” apontando para o servidor CVS do I2P, permitindo desenvolvimento anônimo. Às vezes as pessoas até mesmo executaram proxies “client” para acessar as instâncias “server” apontando para um servidor NNTP.
I2PSnark
I2PSnark desenvolvido por: jrandom, et al, portado do cliente Snark de mjw
Incluído na instalação do I2P, o I2PSnark oferece um cliente BitTorrent anônimo simples com capacidades multitorrent, expondo toda a funcionalidade através de uma interface web HTML simples.
I2Pmail / Susimail
Desenvolvido por: postman, susi23, mastiejaner
I2Pmail é mais um serviço do que uma aplicação — postman oferece email interno e externo com serviço POP3 e SMTP através de instâncias I2PTunnel acessando uma série de componentes desenvolvidos com mastiejaner, permitindo que pessoas usem seus clientes de email preferidos para enviar e receber emails de forma pseudônima. No entanto, como a maioria dos clientes de email expõe informações substanciais de identificação, I2P inclui o cliente web susimail do susi23 que foi construído especificamente com as necessidades de anonimato do I2P em mente. O serviço I2Pmail/mail.i2p oferece filtragem transparente de vírus, bem como prevenção de denial of service com quotas aumentadas por hashcash. Além disso, cada usuário tem controle de sua estratégia de agrupamento antes da entrega através dos outproxies do mail.i2p, que são separados dos servidores SMTP e POP3 do mail.i2p — tanto os outproxies quanto inproxies se comunicam com os servidores SMTP e POP3 do mail.i2p através do próprio I2P, então comprometer essas localizações não-anônimas não dá acesso às contas de email ou padrões de atividade do usuário.