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 a partir de 2025-01.
Introdução
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 conscientes do anonimato ou segurança podem operar. Cada uma dessas aplicações pode fazer suas próprias compensações de anonimato, latência e throughput sem se preocupar com a implementação adequada de uma mixnet de rota livre, permitindo que misturem sua atividade com o conjunto maior de anonimato de usuários já executando em cima do 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 sindicalizaçã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
Diferentemente dos sites hospedados em redes de distribuição de conteúdo como Freenet ou GNUnet , os serviços hospedados no I2P são totalmente interativos — há mecanismos de busca tradicionais no estilo web, fóruns de discussão, blogs nos quais você pode comentar, sites baseados em bancos de dados e pontes para consultar sistemas estáticos como o Freenet sem precisar instalá-lo localmente.
Com todas essas aplicações com anonimato habilitado, o I2P assume o papel de 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 em ordem, 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 existido vários proxies SOCKS simples disponíveis para conectar aplicações existentes à rede, seu valor tem sido limitado, pois quase todas as aplicações rotineiramente expõem o que, em um contexto anônimo, são informações sensíveis. A única forma 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 aproveitar ao máximo a rede.
O I2P não é um projeto de pesquisa — acadêmico, comercial ou governamental — mas sim um esforço de engenharia voltado para fazer o que for necessário para fornecer um nível suficiente de anonimato para aqueles que precisam. Está em desenvolvimento ativo desde o início de 2003 com um desenvolvedor em tempo integral e um grupo dedicado de colaboradores de meio período de todo o mundo. Todo o trabalho realizado no I2P é de código aberto e está disponível gratuitamente no website , com a maior parte 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 que licença as pessoas lançam aplicações cliente, e existem várias aplicações licenciadas sob GPL disponíveis (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex e outras). O financiamento para o I2P vem inteiramente de doações, e não recebe incentivos 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 algo, bem como a qual router um destination específico está conectado. Os usuários finais normalmente terão várias destinations locais em seu router — por exemplo, uma fazendo proxy para servidores IRC, outra suportando o servidor web anônimo do usuário (“I2P Site”), outra para uma instância I2Phex, outra 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. É utilizada encriptação em camadas, de modo que cada um dos routers consegue desencriptar apenas uma única camada. A informação desencriptada contém o IP do próximo router, juntamente com a informação encriptada 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 receptor (“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 as enviará 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 usado para compartilhar metadados da rede. Os dois tipos de metadados transportados são “routerInfo” e “leaseSets” — o routerInfo fornece aos routers os dados necessários para contatar um router específico (suas chaves públicas, endereços de transporte, etc), enquanto o leaseSet fornece aos routers as informações necessárias para contatar 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 enviam diretamente suas routerInfo para o netDb, enquanto os leaseSets são enviados através de túneis de saída (os 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 túneis 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 túneis. Ela pode então enviar uma mensagem de construção para o primeiro hop, solicitando a construção de um túnel e pedindo que esse router envie a mensagem de construção adiante, até que o túnel 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 assim os gateways dos seus tunnels de entrada atuais. Ela então escolhe um dos seus tunnels 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 dos tunnels 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 do tunnel de entrada de Bob a recebe, ela é encaminhada através do tunnel para o router de Bob. Se Alice quiser que Bob possa 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 peers dentro da rede (assim como a própria camada de transporte faz para prevenir divulgação não autorizada para peers fora da rede), é necessário adicionar uma camada adicional de criptografia ponta a ponta para ocultar a mensagem do endpoint do tunnel de saída e do gateway do tunnel de entrada. Esta “garlic encryption ” permite que o router da Alice empacote múltiplas mensagens em uma única “garlic message”, criptografada para uma chave pública específica de modo que peers intermediários não possam determinar quantas mensagens estão dentro do garlic, o que essas mensagens dizem, ou para onde esses dentes individuais estã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 do Bob, permitindo que a mensagem seja criptografada sem divulgar a chave pública para o próprio router do Bob.
Outro fato importante a ter em mente é que o I2P é inteiramente baseado em mensagens e que algumas mensagens podem ser perdidas no 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 servida reutilizando a biblioteca de streaming fornecida para ver o I2P como uma rede baseada em streams.
Tunnels
Tanto os tunnels de entrada quanto os de saída funcionam com princípios semelhantes. O gateway do tunnel acumula várias mensagens do tunnel, eventualmente pré-processando-as em algo adequado 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 separadas 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 ele simplesmente descriptografa todas as camadas adicionadas, enquanto para tunnels de saída, o criador é o gateway e ele pré-descriptografa todas as camadas para que, após todas as camadas de criptografia por salto serem 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. Embora o network database (netDb) tenha 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 orientadas pelas necessidades particulares do cliente em conjunto com seu modelo de ameaças. 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.
De uma perspectiva de 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. De uma perspectiva de desempenho, a técnica mais simples seria escolher os peers mais rápidos com a capacidade de reserva 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 tanto frágil quanto ineficiente, a segunda requer informações inacessíveis e oferece anonimato insuficiente. O I2P está, em vez disso, 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 perfilando os 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-os a ataques triviais. Enquanto coleta esses perfis, uma série de cálculos são executados 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 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 esses dados de perfil, a estratégia mais simples e razoável de seleção de peers é escolher peers aleatoriamente do nível superior (rápido e alta capacidade), e isso está atualmente implementado para tunnels de cliente. Tunnels exploratórios (usados para netDb e gerenciamento de tunnel) 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 escalada de montanha randomizada. Essas 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, abordarão os ataques realizados por classes específicas de adversários.
Ao escolher uma chave aleatória e ordenar os peers de acordo com sua distância XOR a partir 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 precisaria, é claro, ter um limite de duração, já que todos os peers falham eventualmente, então poderia ser ajustado reativamente ou evitado 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 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 mencionada acima, com ordenação baseada em XOR. Uma discussão mais detalhada sobre os mecanismos envolvidos na operação, gerenciamento e seleção de pares de tunnel pode ser encontrada na especificação de tunnel .
Base de Dados da Rede (netDb)
Como mencionado anteriormente, o netDb do I2P trabalha para compartilhar os metadados da rede. Isso é detalhado na página base de dados da rede , mas uma explicação básica está disponível abaixo.
Todos os routers I2P contêm uma netDb local, mas nem todos os routers participam na DHT ou respondem a consultas de leaseSet. Os routers que participam na DHT e respondem a consultas de leaseSet são chamados de ‘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 irão armazenar seus dados e procurar dados enviando consultas simples de ‘store’ e ’lookup’ para os floodfills. Se um router floodfill receber uma consulta ‘store’, ele irá 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 um lookup é feito, o router floodfill não irá encaminhar o lookup 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 da 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 (por exemplo, site I2P, servidor de e-mail…)
Todas essas informações são assinadas pela parte que as publica e verificadas por qualquer router I2P que use ou armazene as informações. Além disso, os dados contêm informações de temporização, para evitar o armazenamento de entradas antigas e possíveis ataques. É por isso também que o I2P inclui o código necessário para manter o tempo correto, consultando ocasionalmente alguns servidores SNTP (o pool.ntp.org round robin 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: Pode-se querer que apenas pessoas específicas consigam alcançar um destino. Isso é possível não publicando o destino no netDb. No entanto, será necessário 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 do netDb é bastante simples. Uma vez que um router consegue receber um único routerInfo de um peer alcançável, ele pode consultar esse router por 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 se conecta automaticamente a um desses websites para coletar arquivos routerInfo e fazer o bootstrap. O I2P chama esse processo de bootstrap de “reseeding”.
Escalabilidade de consulta: As consultas na rede I2P são iterativas, não recursivas. Se uma consulta de um floodfill falhar, a consulta será repetida para o próximo floodfill mais próximo. O floodfill não pergunta recursivamente a outro floodfill pelos dados. Consultas 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, enquanto autentica que o router contactado é aquele que deve receber uma determinada mensagem. Os detalhes específicos de como os routers 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 descontinuados. Ambos os protocolos suportam tanto IPv4 quanto IPv6. Ao suportar transportes TCP e UDP, o I2P pode efetivamente atravessar 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 na base de dados da rede. Routers com acesso a redes IPv4 e IPv6 públicas geralmente publicam quatro endereços, um para cada combinação de NTCP2/SSU2 com IPv4/IPv6.
SSU2 suporta e estende os objetivos do SSU. O 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, o SSU2 fornece facilidades especializadas para detecção cooperativa de endereços IP peer-to-peer, detecção de firewall e atravessamento de NAT. Como descrito na especificação SSU :
O objetivo deste protocolo é fornecer entrega de mensagens segura, autenticada, semi-confiável e desordenada, 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 de PMTU. Deve ser capaz de mover dados em massa de forma eficiente a taxas suficientes para usuários domésticos. Além disso, deve suportar técnicas para lidar com 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.
O 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 determina a prioridade. Os transportes podem responder com lances diferentes, dependendo se já existe 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, número de conexões e outros fatores. Os routers também publicam suas preferências de transporte para conexões de entrada no banco de dados da rede como “custos” de transporte para cada transporte e endereço.
Criptografia
O I2P utiliza 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 base 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. Estas incluíam 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 “dia de bandeira” 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. Estes protocolos modernos são utilizados para a grande maioria da comunicação de rede. Primitivas mais antigas incluindo ElGamal, ECDSA e DSA-SHA1 continuam a ser suportadas pela maioria das implementações para compatibilidade com versões anteriores ao comunicar com routers mais antigos. Alguns protocolos antigos foram depreciados e/ou removidos completamente. Num futuro próximo começaremos a pesquisar uma migração para criptografia e assinaturas pós-quânticas (PQ) ou híbridas-PQ para manter os 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 roteadores é protegida pela segurança da camada de transporte. As mensagens de tunnel passadas através dos transportes têm sua própria encriptação em camadas. Várias outras mensagens são transmitidas dentro de “garlic messages”, que também são encriptadas.
Mensagens Garlic
As mensagens garlic são uma extensão da criptografia em camadas “onion”, permitindo que o conteúdo de uma única mensagem contenha múltiplos “dentes” — mensagens totalmente formadas junto com suas próprias instruções para entrega. As mensagens são envolvidas 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 envolvem 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á envolver 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 cravo dentro da camada de criptografia incluem a capacidade de solicitar que o cravo seja encaminhado localmente, para um router remoto, ou para um tunnel remoto em um router remoto. Existem 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 elas não sejam honradas até que os atrasos não triviais sejam implementados. É possível rotear explicitamente mensagens garlic encryption qualquer número de saltos sem construir tunnels, ou até mesmo rerotear mensagens de tunnel envolvendo-as em mensagens garlic encryption e encaminhando-as um número de saltos antes de entregá-las ao próximo salto no tunnel, mas essas técnicas não são atualmente usadas na implementação existente.
Tags de Sessão
Como um sistema não confiável, não ordenado 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 de dados às garlic messages. A combinação original era chamada de ElGamal/AES+SessionTags, mas essa é uma forma excessivamente verbosa de descrever o uso simples de ElGamal de 2048 bits, 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
Na 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 a carga útil criptografada AES256/CBC após esse bloco ElGamal criptografado. Além da carga útil criptografada, a seção criptografada AES contém o comprimento da carga útil, o hash SHA256 da carga útil não criptografada, bem como uma série 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 com AES a carga útil 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 usado 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 o destinatário com tags suficientes para cobrir uma série de mensagens. As mensagens garlic podem detectar a entrega bem-sucedida da tag ao incluir uma pequena mensagem adicional como um clove (uma “mensagem de status de entrega”) — quando a mensagem garlic chega ao destinatário pretendido e é descriptografada com sucesso, esta pequena mensagem de status de entrega é um dos cloves expostos e tem instruções para o destinatário enviar o clove de volta ao remetente original (através de um tunnel de entrada, é claro). Quando o remetente original recebe esta mensagem de status de entrega, ele sabe que as tags de sessão incluídas 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 utilizados. Além disso, a quantidade armazenada para cada chave é limitada, assim como o número das próprias chaves — se chegarem em excesso, mensagens novas ou antigas podem ser descartadas. O remetente acompanha se as mensagens que usam session tags estão chegando ao destino, e se não houver comunicação suficiente, pode descartar aquelas previamente 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 quantidades de session tags tinham que ser entregues com antecedência, 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 de entrega de session tags.
ECIES-X25519-AEAD-Ratchet foi projetado para resolver essas questões. X25519 é usado para troca de chaves. ChaCha20/Poly1305 é usado para criptografia simétrica autenticada. As chaves de criptografia são “double 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 overhead substancialmente menor 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 é alimentado 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 tags ou chaves 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é-computa uma janela das próximas, por exemplo, 50 tags), 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, há 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 funcionalidades possíveis, rotas restritas e latência variável, foram propostas pelo jrandom em 2003. Embora não planejemos mais implementar essas funcionalidades, elas são descritas abaixo.
Operação de Rota Restrita
I2P é uma rede overlay projetada para ser executada 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 adote mais completamente o princípio fim-a-fim (devido ao uso de NAT), I2P requer que uma porção substancial da rede seja acessível — pode haver um número de peers nas bordas executando usando rotas restritas, mas I2P não inclui um algoritmo de roteamento apropriado para o caso degenerado onde a maioria dos peers são inacessíveis. Funcionaria, no entanto, sobre uma rede que empregasse tal algoritmo.
A operação de rota restrita, onde há limites sobre quais peers são acessíveis diretamente, tem 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 hole punching distribuído 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 para 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 — usar tunnels específicos do router para comunicação e oferecer ‘client routers’. Para o primeiro caso, os routers podem construir um novo conjunto 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, ele 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 para o 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 não publicando nenhum endereço de router. Tal router nem precisaria publicar seu routerInfo no netDb, apenas fornecendo seu routerInfo autoassinado aos peers que contacta (necessário para passar as chaves públicas do router).
Existem compromissos para aqueles que estão atrás de rotas restritas, pois eles provavelmente participariam dos tunnels 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 seriam 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, pressupõe que os peers que o router atrás de uma rota restrita contata não sejam 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 porque peers confiáveis (e talvez temporários) sejam usados em seu lugar.
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 do 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 a 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, ele 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, após um certo número de mensagens terem passado, ou outra estratégia de mistura. Com a criptografia em camadas, apenas o router que o dente de alho expôs a 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 está segurando o dente de alho (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 armazenamento e encaminhamento 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 buscar este objetivo no nível do I2P router.
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 sim da engenharia cuidadosa que combina os resultados de pesquisa de sistemas e artigos existentes. Embora existam alguns esforços semelhantes que valem 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 estar atualmente precisas.
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 no 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, I2P tem uma network database 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 chave é que enquanto tanto I2P quanto Tor usam caminhos em camadas e ordenados (tunnels e circuits/streams), I2P é fundamentalmente uma rede de comutação de pacotes, enquanto Tor é fundamentalmente de comutação de circuitos, permitindo que I2P roteie de forma transparente ao redor de congestionamentos ou outras falhas de rede, opere caminhos redundantes e distribua a carga dos dados através dos recursos disponíveis. Enquanto Tor oferece a funcionalidade útil de outproxy oferecendo descoberta e seleção integrada de outproxy, I2P deixa tais decisões de camada de aplicação para as aplicações executando sobre I2P — de fato, I2P externalizou até mesmo a biblioteca de streaming similar ao TCP para a camada de aplicação, permitindo que 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 similaridade quando as redes principais são comparadas. No entanto, há algumas diferenças-chave. 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 seguiria 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 suficientemente os ataques de predecessor, 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 contagem simples 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 de tunnel unidirecional do I2P com uma única mensagem faz com que esses dados não sejam expostos. Proteger a posição em um tunnel é importante, pois um adversário seria capaz de realizar uma série de ataques poderosos 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 de Internet anônimo de alta velocidade, enquanto I2P trabalha para oferecer uma rede resiliente descentralizada em si mesma. Em teoria, ambos podem ser usados para alcançar ambos os propósitos, mas dados os recursos limitados de desenvolvimento, ambos têm suas forças e fraquezas. Os desenvolvedores do I2P consideraram os passos necessários para modificar 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
O 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 o Freenet, tentando extrair 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 precisariam de uma camada “premix” para oferecer anonimato substancial. Em outras palavras, o 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ído do Freenet.
A funcionalidade do Freenet é muito complementar à do I2P, já que 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 por si só de uma perspectiva de engenharia, anonimato, segurança e alocação de recursos, então esperançosamente a equipe do Freenet perseguirá esforços nessa direção, senão simplesmente reutilizando (ou ajudando a melhorar, conforme necessário) mixnets existentes como I2P ou Tor.
Apêndice A: Camada de Aplicação
O I2P em si não faz muito — 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 funcionalidades adicionais para os usuários finais.
Biblioteca de Streaming
A biblioteca de streaming do 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 comprimidos pareça um compromisso 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 completada em uma única viagem de ida e volta — a primeira mensagem agrupa um SYN, FIN e a pequena carga útil (uma requisição HTTP tipicamente 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, no entanto, 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 Nomenclatura e Livro de Endereços
Para mais informações, consulte a página Nomenclatura e Livro de Endereços .
Desenvolvido por: mihi, Ragnarok
O sistema de nomeação dentro do I2P tem sido um tópico frequentemente 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 tradicional de nomeação estilo DNS está claramente fora de questão, assim como os sistemas de votação de “maioria decide”. Em vez disso, o I2P vem com uma biblioteca de nomeação genérica e uma implementação base projetada para funcionar com um mapeamento local de nome para destination, bem como uma aplicação complementar opcional chamada “Address Book”. O address book é um sistema de nomeação legível por humanos, seguro e distribuído, orientado por 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 similares 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 que com o I2P, solicitações enviadas para um destino não podem ser interceptadas ou a resposta falsificada, pois são criptografadas com as chaves públicas do destino, e um destino em si é apenas um par de chaves públicas e um certificado. Sistemas no estilo DNS, por outro lado, permitem que qualquer um dos servidores de nomes no caminho de consulta realize ataques simples de negação de serviço e falsificação. Adicionar um certificado que autentica as respostas como assinadas por alguma autoridade certificadora centralizada resolveria muitos dos problemas de servidores de nomes hostis, mas deixaria em aberto ataques de replay, bem como ataques de autoridades certificadoras hostis.
O sistema de nomenclatura por votação também é perigoso, 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 assumir o controle de um determinado nome. Métodos de proof-of-work podem ser usados para tornar a identidade não gratuita, mas à medida que a rede cresce, a carga necessária para contatar todos para conduzir uma votação online se torna inviável, ou se toda a rede não for consultada, diferentes conjuntos de respostas podem ser alcançados.
Assim como na Internet, contudo, o I2P está mantendo o design e operação de um sistema de nomes fora da camada de comunicação (similar ao IP). A biblioteca de nomes incluída possui uma interface simples de provedor de serviços na qual sistemas de nomes alternativos podem se conectar, permitindo que os usuários finais decidam que tipo de compromissos de nomenclatura eles 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 “cliente” que recebe conexões TCP de entrada e as encaminha para um determinado destino I2P, um “httpclient” (também conhecido como “eepproxy”) que atua como um proxy HTTP e encaminha as solicitações para o destino I2P apropriado (após consultar o serviço de nomeação, se necessário), um “servidor” que recebe conexões de streaming I2P de entrada em um destino e as encaminha para um determinado host+porta TCP, e um “httpserver” que estende o “servidor” analisando as solicitações e respostas HTTP para permitir operação mais segura. Há uma aplicação adicional “socksclient”, mas seu uso não é encorajado pelas razões mencionadas 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 I2PTunnel “httpclient” oferece um gancho para outproxying — se o hostname 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 I2PTunnel “server” executadas por voluntários que escolheram explicitamente executar outproxies — ninguém é um outproxy por padrão, e executar um outproxy não informa automaticamente 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 algumas funcionalidades sob um modelo de ameaça que pode ser suficiente para alguns usuários.
I2PTunnel permite a maioria das aplicações em uso. Um “httpserver” apontando para um servidor web permite que qualquer pessoa execute seu próprio site anônimo (ou “Site I2P”) — um servidor web está incluído no I2P para esse 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 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é 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 — o postman oferece email interno e externo com serviço POP3 e SMTP através de instâncias I2PTunnel que acessam uma série de componentes desenvolvidos com mastiejaner, permitindo que as 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 de identificação substanciais, o I2P inclui o cliente susimail baseado na web 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 negação de serviço com cotas 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 os 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.