ПРИМЕЧАНИЕ: Этот документ был изначально написан jrandom в 2003 году. Хотя мы стремимся поддерживать его актуальность, некоторая информация может быть устаревшей или неполной. Разделы о транспорте и криптографии актуальны на январь 2025 года.
Введение
I2P — это масштабируемый, самоорганизующийся, устойчивый анонимный сетевой уровень с коммутацией пакетов, поверх которого может работать любое количество различных приложений, ориентированных на анонимность или безопасность. Каждое из этих приложений может самостоятельно балансировать анонимность, задержки и пропускную способность, не беспокоясь о правильной реализации свободной маршрутной mixnet, что позволяет им смешивать свою активность с более широким набором анонимности пользователей, уже работающих поверх I2P.
Доступные приложения обеспечивают полный спектр типичных интернет-активностей — анонимный веб-серфинг, веб-хостинг, чат, обмен файлами, электронную почту, ведение блогов и синдикацию контента, а также несколько других приложений, находящихся в разработке.
- Веб-серфинг: использование любого существующего браузера, который поддерживает работу через прокси.
- Чат: IRC и другие протоколы
- Обмен файлами: I2PSnark и другие приложения
- Электронная почта: susimail и другие приложения
- Блог: использование любого локального веб-сервера или доступных плагинов
В отличие от веб-сайтов, размещенных в сетях распространения контента, таких как Freenet или GNUnet , службы, размещенные в I2P, являются полностью интерактивными — здесь есть традиционные поисковые системы веб-стиля, доски объявлений, блоги, на которые можно комментировать, сайты на основе баз данных и мосты для запросов к статическим системам, таким как Freenet, без необходимости локальной установки.
Со всеми этими приложениями с поддержкой анонимности I2P берет на себя роль промежуточного программного обеспечения, ориентированного на сообщения — приложения заявляют, что хотят отправить некоторые данные криптографическому идентификатору («destination»), а I2P заботится о том, чтобы они попали туда безопасно и анонимно. I2P также включает простую потоковую библиотеку, которая позволяет анонимным сообщениям I2P с максимальными усилиями передаваться как надежные, упорядоченные потоки, прозрачно предлагая алгоритм контроля перегрузки на основе TCP, настроенный для высокого произведения пропускной способности на задержку сети. Хотя было доступно несколько простых SOCKS-прокси для подключения существующих приложений к сети, их ценность была ограниченной, поскольку почти каждое приложение регулярно раскрывает то, что в анонимном контексте является чувствительной информацией. Единственный безопасный способ — это полностью проверить приложение для обеспечения правильной работы, и чтобы помочь в этом, мы предоставляем серию API на различных языках, которые можно использовать для максимального использования возможностей сети.
I2P не является исследовательским проектом — академическим, коммерческим или государственным — а представляет собой инженерную разработку, направленную на то, чтобы делать всё необходимое для обеспечения достаточного уровня анонимности тем, кто в этом нуждается. Проект находится в активной разработке с начала 2003 года, в нём участвует один штатный разработчик и преданная команда разработчиков-волонтёров со всего мира. Вся работа над I2P является открытым исходным кодом и свободно доступна на веб-сайте , при этом большая часть кода полностью передана в общественное достояние, хотя и использует несколько криптографических процедур под BSD-подобными лицензиями. Люди, работающие над I2P, не контролируют под какими лицензиями люди выпускают клиентские приложения, и доступно несколько приложений под GPL (I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex и другие). Финансирование I2P поступает исключительно от пожертвований и не получает никаких налоговых льгот ни в одной юрисдикции в настоящее время, поскольку многие из разработчиков сами являются анонимными.
Работа
Обзор
Чтобы понять работу I2P, необходимо усвоить несколько ключевых концепций. Во-первых, I2P строго разделяет программное обеспечение, участвующее в сети (router), и анонимные конечные точки (destinations), связанные с отдельными приложениями. То, что кто-то использует I2P, обычно не является секретом. Скрывается информация о том, что делает пользователь, если вообще что-то делает, а также к какому router подключён конкретный destination. Конечные пользователи обычно имеют несколько локальных destinations на своём router — например, один для проксирования на IRC-серверы, другой для поддержки анонимного веб-сервера пользователя («I2P Site»), третий для экземпляра I2Phex, четвёртый для торрентов и так далее.
Другая критически важная концепция для понимания — это “tunnel”. Tunnel — это направленный путь через явно выбранный список router’ов. Используется многослойное шифрование, поэтому каждый из router’ов может расшифровать только один слой. Расшифрованная информация содержит IP следующего router’а вместе с зашифрованной информацией, которая должна быть передана дальше. Каждый tunnel имеет начальную точку (первый router, также известный как “gateway”) и конечную точку. Сообщения могут отправляться только в одном направлении. Для отправки сообщений обратно требуется другой tunnel.
Существует два типа tunnel: “исходящие” tunnel отправляют сообщения от создателя tunnel, в то время как “входящие” tunnel доставляют сообщения к создателю tunnel. Комбинируя эти два tunnel, пользователи могут отправлять сообщения друг другу. Отправитель (“Alice” на изображении выше) настраивает исходящий tunnel, в то время как получатель (“Bob” на изображении выше) создает входящий tunnel. Gateway входящего tunnel может получать сообщения от любого другого пользователя и будет передавать их до конечной точки (“Bob”). Конечная точка исходящего tunnel должна будет переслать сообщение на gateway входящего tunnel. Для этого отправитель (“Alice”) добавляет инструкции в свое зашифрованное сообщение. Как только конечная точка исходящего tunnel расшифрует сообщение, она получит инструкции по пересылке сообщения на правильный входящий gateway (gateway к “Bob”).
Третья критически важная концепция для понимания — это “network database” I2P (или “netDb”) — пара алгоритмов, используемых для обмена метаданными сети. Два типа передаваемых метаданных — это “routerInfo” и “leaseSets” — routerInfo предоставляет router’ам данные, необходимые для связи с конкретным router’ом (их публичные ключи, транспортные адреса и т.д.), в то время как leaseSet предоставляет router’ам информацию, необходимую для связи с конкретным назначением. leaseSet содержит несколько “lease” (аренд). Каждая из этих аренд указывает шлюз tunnel’я, который позволяет достичь определенного назначения. Полная информация, содержащаяся в аренде:
- Входящий gateway для tunnel, который позволяет достичь определённого назначения.
- Время истечения срока действия tunnel.
- Пара открытых ключей для возможности шифрования сообщений (для отправки через tunnel и достижения назначения).
Router’ы сами отправляют свою routerInfo в netDb напрямую, в то время как leaseSet’ы отправляются через исходящие tunnel’ы (leaseSet’ы должны отправляться анонимно, чтобы избежать корреляции router’а с его leaseSet’ами).
Мы можем объединить вышеупомянутые концепции для построения успешных соединений в сети.
Чтобы построить свои входящие и исходящие tunnel, Алиса выполняет поиск в netDb для сбора routerInfo. Таким образом, она собирает списки узлов, которые может использовать в качестве промежуточных точек в своих tunnel. Затем она может отправить сообщение построения первому узлу, запрашивая создание tunnel и прося этот router переслать сообщение построения дальше, пока tunnel не будет создан.
Когда Алиса хочет отправить сообщение Бобу, она сначала выполняет поиск в netDb, чтобы найти leaseSet Боба, получая информацию о его текущих входящих tunnel шлюзах. Затем она выбирает один из своих исходящих tunnel и отправляет сообщение по нему с инструкциями для конечной точки исходящего tunnel переслать сообщение на один из входящих tunnel шлюзов Боба. Когда конечная точка исходящего tunnel получает эти инструкции, она пересылает сообщение согласно запросу, а когда входящий tunnel шлюз Боба получает его, сообщение пересылается по tunnel к router Боба. Если Алиса хочет, чтобы Боб мог ответить на сообщение, ей необходимо явно передать свой собственный пункт назначения как часть самого сообщения. Это можно сделать, введя слой более высокого уровня, что реализовано в библиотеке streaming . Алиса также может сократить время ответа, прикрепив свой самый последний LeaseSet к сообщению, чтобы Бобу не нужно было выполнять поиск netDb для этого, когда он захочет ответить, но это опционально.
Хотя сами tunnel имеют многоуровневое шифрование для предотвращения несанкционированного раскрытия информации узлам внутри сети (как и транспортный уровень предотвращает несанкционированное раскрытие информации узлам вне сети), необходимо добавить дополнительный сквозной уровень шифрования, чтобы скрыть сообщение от конечной точки исходящего tunnel и шлюза входящего tunnel. Это “garlic encryption ” позволяет router Алисы упаковать несколько сообщений в одно “garlic сообщение”, зашифрованное определенным открытым ключом, чтобы промежуточные узлы не могли определить ни количество сообщений внутри garlic, ни содержание этих сообщений, ни место назначения отдельных частей. Для типичной сквозной связи между Алисой и Бобом garlic будет зашифровано открытым ключом, опубликованным в leaseSet Боба, что позволяет зашифровать сообщение, не раскрывая открытый ключ собственному router Боба.
Другой важный факт, который следует помнить, это то, что I2P полностью основана на сообщениях и что некоторые сообщения могут быть потеряны по пути. Приложения, использующие I2P, могут использовать интерфейсы, ориентированные на сообщения, и заботиться о своих собственных потребностях в контроле перегрузки и надежности, но большинству лучше всего подойдет повторное использование предоставленной библиотеки streaming для рассмотрения I2P как сети на основе потоков.
Tunnels
Как входящие, так и исходящие туннели работают по схожим принципам. Шлюз туннеля накапливает несколько сообщений туннеля, в конечном итоге предварительно обрабатывая их во что-то для доставки через туннель. Затем шлюз шифрует эти предварительно обработанные данные и пересылает их на первый hop. Этот узел и последующие участники туннеля добавляют слой шифрования после проверки того, что это не дубликат, прежде чем переслать его следующему узлу. В конечном итоге сообщение прибывает в конечную точку, где сообщения снова разделяются и пересылаются по запросу. Разница возникает в том, что делает создатель туннеля — для входящих туннелей создатель является конечной точкой и он просто расшифровывает все добавленные слои, в то время как для исходящих туннелей создатель является шлюзом и он предварительно расшифровывает все слои так, что после добавления всех слоев шифрования для каждого hop, сообщение прибывает в открытом виде в конечную точку туннеля.
Выбор конкретных peers для передачи сообщений, а также их определенный порядок важны для понимания как анонимности I2P, так и характеристик производительности. Хотя network database (см. ниже) имеет свои собственные критерии для выбора peers для запросов и хранения записей, создатели туннелей могут использовать любых peers в сети в любом порядке (и даже любое количество раз) в одном tunnel. Если бы данные о задержке и пропускной способности были идеально известны глобально, выбор и упорядочивание определялись бы конкретными потребностями клиента в сочетании с их моделью угроз. К сожалению, данные о задержке и пропускной способности нетривиально собирать анонимно, а зависимость от недоверенных peers для предоставления этой информации имеет свои серьезные последствия для анонимности.
С точки зрения анонимности самой простой техникой было бы случайно выбирать узлы из всей сети, случайно упорядочивать их и использовать эти узлы в таком порядке навечно. С точки зрения производительности самой простой техникой было бы выбирать самые быстрые узлы с необходимой свободной пропускной способностью, распределяя нагрузку между различными узлами для обработки прозрачного переключения при отказе, и перестраивать tunnel всякий раз, когда изменяется информация о пропускной способности. Хотя первый подход и хрупок, и неэффективен, последний требует недоступной информации и предлагает недостаточную анонимность. Вместо этого I2P работает над предложением ряда стратегий выбора узлов в сочетании с кодом измерений, учитывающим анонимность, для организации узлов по их профилям.
В качестве основы I2P постоянно профилирует узлы, с которыми взаимодействует, измеряя их косвенное поведение — например, когда узел отвечает на запрос netDb за 1,3 секунды, эта задержка передачи туда и обратно записывается в профили всех router’ов, участвующих в двух tunnel’ах (входящем и исходящем), через которые прошли запрос и ответ, а также в профиль запрашиваемого узла. Прямые измерения, такие как задержка или перегрузка на транспортном уровне, не используются как часть профиля, поскольку ими можно манипулировать и связать с измеряющим router’ом, подвергая его тривиальным атакам. При сборе этих профилей выполняется ряд вычислений для каждого из них, чтобы обобщить его производительность — его задержку, способность справляться с большим объемом активности, перегружен ли он в данный момент и насколько хорошо он интегрирован в сеть. Затем эти вычисления сравниваются для активных узлов, чтобы организовать router’ы в четыре уровня — быстрые и высокопроизводительные, высокопроизводительные, не отказывающие и отказывающие. Пороги для этих уровней определяются динамически, и хотя в настоящее время используются довольно простые алгоритмы, существуют альтернативы.
Используя эти данные профиля, простейшая разумная стратегия выбора узлов состоит в случайном выборе узлов из верхнего уровня (быстрые и высокопроизводительные), и это в настоящее время применяется для клиентских tunnel’ов. Исследовательские tunnel’ы (используемые для netDb и управления tunnel’ами) случайно выбирают узлы из уровня “не отказывающих” (который также включает router’ы из ‘лучших’ уровней), позволяя узлу более широко исследовать router’ы, фактически оптимизируя выбор узлов через рандомизированный поиск по холмам . Однако только эти стратегии действительно утекают информацию о узлах в верхнем уровне router’а через атаки предшественников и сбора данных netDb. В свою очередь, существует несколько альтернатив, которые, хотя и не балансируют нагрузку так равномерно, устранят атаки, осуществляемые определенными классами противников.
Выбирая случайный ключ и упорядочивая узлы согласно их XOR расстоянию от него, утечка информации снижается при атаках предшественника и сбора данных в соответствии с частотой отказов узлов и оттоком уровня. Другая простая стратегия для борьбы с атаками сбора данных netDb заключается в простом фиксировании входящего gateway(ов) tunnel, при этом рандомизируя узлы дальше в tunnel. Для борьбы с атаками предшественника для противников, с которыми контактирует клиент, конечные точки исходящего tunnel также остались бы фиксированными. Выбор того, какой узел зафиксировать в наиболее уязвимой точке, конечно, должен иметь ограничение по продолжительности, поскольку все узлы в конечном итоге выходят из строя, поэтому это может быть либо реактивно скорректировано, либо проактивно предотвращено для имитации измеренного среднего времени между отказами других router. Эти две стратегии в свою очередь могут быть объединены, используя фиксированный уязвимый узел и XOR-основанное упорядочивание внутри самих tunnel. Более жесткая стратегия зафиксировала бы точных узлов и порядок потенциального tunnel, используя отдельных узлов только если все они согласны участвовать одинаково каждый раз. Это отличается от XOR-основанного упорядочивания тем, что предшественник и преемник каждого узла всегда одинаковы, в то время как XOR только гарантирует, что их порядок не изменится.
Как упоминалось ранее, I2P в настоящее время (релиз 0.8) включает описанную выше многоуровневую случайную стратегию с упорядочиванием на основе XOR. Более подробное обсуждение механизмов, задействованных в работе tunnel, управлении и выборе узлов можно найти в спецификации tunnel .
Сетевая база данных (netDb)
Как упоминалось ранее, netDb I2P работает для обмена метаданными сети. Это подробно описано на странице база данных сети , но ниже доступно базовое объяснение.
Все router’ы I2P содержат локальную netDb, но не все router’ы участвуют в DHT или отвечают на запросы поиска leaseSet. Те router’ы, которые участвуют в DHT и отвечают на запросы поиска leaseSet, называются ‘floodfill’. Router’ы могут быть вручную настроены как floodfill или автоматически становиться floodfill, если у них достаточно мощности и они соответствуют другим критериям надёжной работы.
Другие I2P router будут хранить свои данные и искать данные, отправляя простые запросы ‘store’ и ’lookup’ на floodfill. Если floodfill router получает запрос ‘store’, он распространит информацию на другие floodfill router, используя алгоритм Kademlia . Запросы ’lookup’ в настоящее время работают по-другому, чтобы избежать важной проблемы безопасности. Когда выполняется lookup, floodfill router не будет пересылать lookup другим узлам, а всегда будет отвечать самостоятельно (если у него есть запрашиваемые данные).
Два типа информации хранятся в сетевой базе данных.
- RouterInfo хранит информацию о конкретном I2P router и способах связи с ним
- LeaseSet хранит информацию о конкретном назначении (например, I2P веб-сайт, почтовый сервер…)
Вся эта информация подписывается публикующей стороной и проверяется любым I2P router, использующим или хранящим эту информацию. Кроме того, данные содержат информацию о времени, чтобы избежать хранения устаревших записей и возможных атак. Именно поэтому I2P включает в себя необходимый код для поддержания правильного времени, периодически запрашивая некоторые SNTP серверы (pool.ntp.org round robin по умолчанию) и обнаруживая расхождения во времени между router на транспортном уровне.
Также важны некоторые дополнительные замечания.
Неопубликованные и зашифрованные leaseSet: Может возникнуть желание, чтобы только определенные люди могли достичь место назначения. Это возможно, если не публиковать место назначения в netDb. Однако вам придется передавать место назначения другими способами. Это поддерживается с помощью ‘зашифрованных leaseSets’. Эти leaseSets могут быть декодированы только людьми, имеющими доступ к ключу расшифровки.
Bootstrapping: Bootstrapping netDb довольно прост. Как только router удается получить единственный routerInfo доступного узла, он может запросить у этого router ссылки на другие router в сети. В настоящее время ряд пользователей размещают свои файлы routerInfo на веб-сайте, чтобы сделать эту информацию доступной. I2P автоматически подключается к одному из этих веб-сайтов для сбора файлов routerInfo и bootstrap. I2P называет этот процесс bootstrap “reseeding”.
Масштабируемость поиска: Поиски в сети I2P являются итеративными, а не рекурсивными. Если поиск от floodfill не удается, поиск будет повторен к следующему ближайшему floodfill. Floodfill не запрашивает данные рекурсивно у другого floodfill. Итеративные поиски масштабируются для больших DHT-сетей.
Транспортные протоколы
Связь между router-ами должна обеспечивать конфиденциальность и целостность против внешних противников, при этом аутентифицируя, что контактируемый router является тем, кто должен получить данное сообщение. Особенности того, как router-ы взаимодействуют с другими router-ами, не критичны — три отдельных протокола использовались в разные моменты времени для обеспечения этих основных потребностей.
I2P в настоящее время поддерживает два транспортных протокола: NTCP2 поверх TCP и SSU2 поверх UDP. Они заменили предыдущие версии протоколов NTCP и SSU , которые теперь устарели. Оба протокола поддерживают как IPv4, так и IPv6. Поддерживая транспорты как TCP, так и UDP, I2P может эффективно преодолевать большинство межсетевых экранов, включая те, которые предназначены для блокировки трафика в условиях ограничительных режимов цензуры. NTCP2 и SSU2 были разработаны для использования современных стандартов шифрования, улучшения сопротивления идентификации трафика, повышения эффективности и безопасности, а также для более надежного преодоления NAT. Router’ы публикуют каждый поддерживаемый транспорт и IP-адрес в базе данных сети. Router’ы с доступом к публичным IPv4 и IPv6 сетям обычно публикуют четыре адреса — по одному для каждой комбинации NTCP2/SSU2 с IPv4/IPv6.
SSU2 поддерживает и расширяет цели SSU. SSU2 имеет много общего с другими современными протоколами на основе UDP, такими как Wireguard и QUIC. Помимо надежной передачи сетевых сообщений по UDP, SSU2 предоставляет специализированные возможности для peer-to-peer, совместного обнаружения IP-адресов, обнаружения межсетевых экранов и обхода NAT. Как описано в спецификации SSU :
Цель данного протокола — обеспечить безопасную, аутентифицированную, полунадежную и неупорядоченную доставку сообщений, раскрывая только минимальное количество данных, легко распознаваемых третьими сторонами. Он должен поддерживать высокую степень связи, а также TCP-дружественное управление перегрузкой и может включать обнаружение PMTU. Он должен быть способен эффективно перемещать большие объемы данных со скоростью, достаточной для домашних пользователей. Кроме того, он должен поддерживать методы преодоления сетевых препятствий, таких как большинство NAT или межсетевых экранов.
NTCP2 поддерживает и расширяет цели NTCP. Он обеспечивает эффективную и полностью зашифрованную передачу сетевых сообщений по TCP, а также устойчивость к идентификации трафика, используя современные стандарты шифрования.
I2P поддерживает несколько транспортов одновременно. Конкретный транспорт для исходящего соединения выбирается с помощью “ставок”. Каждый транспорт делает ставку на соединение, и относительное значение этих ставок определяет приоритет. Транспорты могут отвечать разными ставками в зависимости от того, существует ли уже установленное соединение с узлом.
Значения bid (приоритета) зависят от реализации и могут варьироваться в зависимости от условий трафика, количества соединений и других факторов. Router’ы также публикуют свои предпочтения транспорта для входящих соединений в сетевой базе данных как транспортные “затраты” для каждого транспорта и адреса.
Криптография
I2P использует криптографию на нескольких уровнях протокола для шифрования, аутентификации и верификации. Основными уровнями протокола являются: транспорты, сообщения построения tunnel, шифрование уровня tunnel, сообщения network database и сквозные (garlic) сообщения. Первоначальная архитектура I2P использовала небольшой набор криптографических примитивов, которые на тот момент считались безопасными. К ним относились асимметричное шифрование ElGamal, подписи DSA-SHA1, симметричное шифрование AES256/CBC и хеши SHA-256. По мере роста доступной вычислительной мощности и существенного развития криптографических исследований на протяжении лет, I2P потребовалось обновить свои примитивы и протоколы. Поэтому мы добавили концепцию “типов шифрования” и “типов подписей”, и расширили наши протоколы, включив эти идентификаторы и указание поддержки. Это позволяет нам периодически обновлять и расширять сетевую поддержку современной криптографии и готовить сеть к новым примитивам, не нарушая обратную совместимость и не требуя “дня флага” для обновлений сети. Некоторые типы подписей и шифрования также зарезервированы для экспериментального использования.
Текущие криптографические примитивы, используемые на большинстве уровней протокола, включают обмен ключами X25519, подписи EdDSA, аутентифицированное симметричное шифрование ChaCha20/Poly1305 и хеши SHA-256. AES256 по-прежнему используется для шифрования на уровне tunnel. Эти современные протоколы применяются для подавляющего большинства сетевых коммуникаций. Более старые примитивы, включая ElGamal, ECDSA и DSA-SHA1, продолжают поддерживаться большинством реализаций для обратной совместимости при взаимодействии со старыми router. Некоторые старые протоколы были объявлены устаревшими и/или полностью удалены. В ближайшем будущем мы начнем исследование перехода к постквантовому (PQ) или гибридному PQ шифрованию и подписям для поддержания наших надежных стандартов безопасности.
Эти криптографические примитивы объединены вместе, чтобы обеспечить многоуровневую защиту I2P от различных противников. На самом низком уровне связь между router защищена безопасностью транспортного уровня. Сообщения tunnel , передаваемые по транспортам, имеют собственное многоуровневое шифрование. Различные другие сообщения передаются внутри “garlic messages”, которые также зашифрованы.
Garlic Messages
Garlic-сообщения представляют собой расширение «луковичного» слоистого шифрования, позволяющее содержимому одного сообщения включать несколько «зубчиков» — полностью сформированные сообщения вместе с их собственными инструкциями для доставки. Сообщения заворачиваются в garlic-сообщение всякий раз, когда сообщение иначе проходило бы в открытом виде через узел, который не должен иметь доступ к информации — например, когда router хочет попросить другой router участвовать в tunnel, он заворачивает запрос внутрь garlic, шифрует этот garlic открытым ключом принимающего router и пересылает его через tunnel. Другим примером является случай, когда клиент хочет отправить сообщение получателю — router отправителя завернет это сообщение с данными (вместе с некоторыми другими сообщениями) в garlic, зашифрует этот garlic открытым ключом, опубликованным в leaseSet получателя, и переправит его через соответствующие tunnel.
“Инструкции”, прикрепленные к каждому clove внутри слоя шифрования, включают возможность запросить, чтобы clove был перенаправлен локально, на удаленный router или в удаленный tunnel на удаленном router. В этих инструкциях есть поля, позволяющие peer-узлу запросить задержку доставки до определенного времени или выполнения определенного условия, хотя они не будут выполняться до развертывания нетривиальных задержек . Возможно явно маршрутизировать garlic-сообщения через любое количество hop-ов без построения tunnel-ов, или даже перенаправлять сообщения tunnel-ов, обернув их в garlic-сообщения и переслав их через несколько hop-ов перед доставкой на следующий hop в tunnel, но эти техники в настоящее время не используются в существующей реализации.
Теги сессий
Как ненадежная, неупорядоченная система, основанная на сообщениях, I2P использует простую комбинацию асимметричных и симметричных алгоритмов шифрования для обеспечения конфиденциальности и целостности данных в garlic-сообщениях. Первоначальная комбинация называлась ElGamal/AES+SessionTags, но это чрезмерно подробный способ описания простого использования 2048-битного ElGamal, AES256, SHA256 и 32-байтовых nonce. Хотя этот протокол все еще поддерживается, большая часть сети перешла на новый протокол ECIES-X25519-AEAD-Ratchet. Этот протокол объединяет X25519, ChaCha20/Poly1305 и синхронизированный PRNG для генерации 32-байтовых nonce. Оба протокола будут кратко описаны ниже.
ElGamal/AES+SessionTags
При первом желании router зашифровать garlic-сообщение другому router, он шифрует ключевой материал для сессионного ключа AES256 с помощью ElGamal и добавляет зашифрованную AES256/CBC полезную нагрузку после этого зашифрованного блока ElGamal. В дополнение к зашифрованной полезной нагрузке, зашифрованная AES секция содержит длину полезной нагрузки, SHA256 хэш незашифрованной полезной нагрузки, а также несколько “session tags” — случайные 32-байтовые одноразовые номера. В следующий раз, когда отправитель хочет зашифровать garlic-сообщение другому router, вместо ElGamal-шифрования нового сессионного ключа он просто выбирает один из ранее доставленных session tags и AES-шифрует полезную нагрузку как раньше, используя сессионный ключ, использовавшийся с этим session tag, добавляя в начало сам session tag. Когда router получает garlic-зашифрованное сообщение, он проверяет первые 32 байта, чтобы увидеть, соответствует ли это доступному session tag — если да, он просто AES-расшифровывает сообщение, но если нет, он ElGamal-расшифровывает первый блок.
Каждый session tag может использоваться только один раз, чтобы предотвратить ненужную корреляцию различных сообщений внутренними противниками как передаваемых между одними и теми же router’ами. Отправитель сообщения, зашифрованного ElGamal/AES+SessionTag, выбирает, когда и сколько тегов доставить, заранее обеспечивая получателя достаточным количеством тегов для покрытия серии сообщений. Garlic-сообщения могут обнаружить успешную доставку тегов, включая небольшое дополнительное сообщение в качестве clove (“сообщение о статусе доставки”) — когда garlic-сообщение прибывает к предполагаемому получателю и успешно расшифровывается, это небольшое сообщение о статусе доставки является одним из обнаруженных clove и содержит инструкции для получателя отправить clove обратно первоначальному отправителю (через входящий tunnel, конечно). Когда первоначальный отправитель получает это сообщение о статусе доставки, он знает, что session tag’и, включенные в garlic-сообщение, были успешно доставлены.
Сами session tags имеют очень короткое время жизни, после чего они отбрасываются, если не используются. Кроме того, количество, хранящееся для каждого ключа, ограничено, как и само количество ключей — если поступает слишком много, могут быть отброшены как новые, так и старые сообщения. Отправитель отслеживает, проходят ли сообщения, использующие session tags, и если нет достаточной связи, он может отбросить те, которые ранее считались правильно доставленными, вернувшись к полному дорогостоящему ElGamal шифрованию.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags требовал существенных накладных расходов по нескольким направлениям. Использование CPU было высоким, поскольку ElGamal работает довольно медленно. Пропускная способность была чрезмерной из-за необходимости заранее доставлять большое количество session tags, а также из-за того, что открытые ключи ElGamal очень большие. Использование памяти было высоким из-за требования хранить большие объемы session tags. Надежность страдала из-за потери доставки session tags.
ECIES-X25519-AEAD-Ratchet был разработан для решения этих проблем. X25519 используется для обмена ключами. ChaCha20/Poly1305 используется для аутентифицированного симметричного шифрования. Ключи шифрования “двойным трещоткованием” или периодически ротируются. Теги сессий сокращены с 32 байт до 8 байт и генерируются с помощью PRNG. Протокол имеет много сходств с протоколом signal, используемым в Signal и WhatsApp. Этот протокол обеспечивает существенно меньшие накладные расходы по CPU, оперативной памяти и пропускной способности.
Теги сессии генерируются из детерминированного синхронизированного PRNG, работающего на обоих концах сессии для создания тегов сессии и ключей сессии. PRNG представляет собой HKDF, использующий SHA-256 HMAC, и инициализируется результатом X25519 DH. Теги сессии никогда не передаются заранее; они включаются только вместе с сообщением. Получатель хранит ограниченное количество ключей сессии, индексированных по тегу сессии. Отправителю не нужно хранить какие-либо теги или ключи сессии, поскольку они не отправляются заранее; они могут генерироваться по требованию. Поддерживая этот PRNG примерно синхронизированным между отправителем и получателем (получатель предвычисляет окно следующих, например, 50 тегов), устраняются накладные расходы на периодическую группировку большого количества тегов.
Будущее
Протоколы I2P эффективны на большинстве платформ, включая мобильные телефоны, и безопасны для большинства моделей угроз. Однако существует несколько областей, которые требуют дальнейшего улучшения для удовлетворения потребностей тех, кто сталкивается с мощными государственными противниками, а также для противодействия угрозам постоянного развития криптографии и постоянно растущей вычислительной мощности. Две возможные функции, ограниченные маршруты и переменная задержка, были предложены jrandom в 2003 году. Хотя мы больше не планируем реализовывать эти функции, они описаны ниже.
Работа с ограниченными маршрутами
I2P — это оверлейная сеть, предназначенная для работы поверх функционирующей пакетно-коммутируемой сети, использующая принцип “от конца к концу” для обеспечения анонимности и безопасности. Хотя Интернет больше не полностью придерживается принципа “от конца к концу” (из-за использования NAT), I2P требует, чтобы существенная часть сети была достижима — может быть некоторое количество узлов на краях, работающих с ограниченными маршрутами, но I2P не включает подходящий алгоритм маршрутизации для вырожденного случая, когда большинство узлов недостижимы. Однако он будет работать поверх сети, использующей такой алгоритм.
Работа с ограниченными маршрутами, где существуют ограничения на то, какие узлы доступны напрямую, имеет несколько различных функциональных и анонимных последствий, зависящих от того, как обрабатываются ограниченные маршруты. На самом базовом уровне ограниченные маршруты существуют, когда узел находится за NAT или брандмауэром, который не разрешает входящие соединения. Это было в значительной степени решено путем интеграции распределенного пробивания дыр в транспортный уровень, позволяя людям за большинством NAT и брандмауэров получать незапрошенные соединения без какой-либо настройки. Однако это не ограничивает раскрытие IP-адреса узла для router’ов внутри сети, поскольку они могут просто получить представление узлу через опубликованный introducer.
Помимо функциональной обработки ограниченных маршрутов, существуют два уровня ограниченной работы, которые можно использовать для ограничения раскрытия IP-адреса — использование специфичных для router туннелей для связи и предложение ‘клиентских router’. В первом случае router могут либо построить новый пул туннелей, либо повторно использовать свой исследовательский пул, публикуя входящие шлюзы к некоторым из них как часть своего routerInfo вместо адресов транспорта. Когда узел хочет связаться с ними, он видит эти туннельные шлюзы в netDb и просто отправляет соответствующее сообщение к ним через один из опубликованных туннелей. Если узел за ограниченным маршрутом хочет ответить, он может сделать это либо напрямую (если готов раскрыть свой IP узлу), либо косвенно через свои исходящие туннели. Когда router, к которым у узла есть прямые соединения, хотят связаться с ним (например, для пересылки туннельных сообщений), они просто приоритизируют своё прямое соединение над опубликованным туннельным шлюзом. Концепция ‘клиентских router’ просто расширяет ограниченный маршрут, не публикуя никаких адресов router. Такому router даже не нужно было бы публиковать свой routerInfo в netDb, лишь предоставляя свой самоподписанный routerInfo узлам, с которыми он контактирует (необходимо для передачи публичных ключей router).
Существуют компромиссы для тех, кто находится за ограниченными маршрутами, поскольку они, вероятно, будут реже участвовать в tunnel других людей, а router’ы, к которым они подключены, смогут определить паттерны трафика, которые иначе не были бы раскрыты. С другой стороны, если стоимость такого раскрытия меньше стоимости предоставления IP-адреса, это может быть целесообразно. Это, конечно, предполагает, что узлы, с которыми связывается router за ограниченным маршрутом, не являются враждебными — либо сеть достаточно велика, чтобы вероятность использования враждебного узла для подключения была достаточно мала, либо вместо этого используются доверенные (и, возможно, временные) узлы.
Ограниченные маршруты сложны, и общая цель была в значительной степени оставлена. Несколько связанных улучшений значительно снизили потребность в них. Теперь мы поддерживаем UPnP для автоматического открытия портов межсетевого экрана. Мы поддерживаем как IPv4, так и IPv6. SSU2 улучшил определение адресов, определение состояния межсетевого экрана и кооперативное пробивание NAT. SSU2, NTCP2 и проверки совместимости адресов обеспечивают возможность подключения узлов tunnel перед построением tunnel. GeoIP и идентификация стран позволяют нам избегать узлов в странах с ограничительными межсетевыми экранами. Поддержка “скрытых” router за такими межсетевыми экранами улучшилась. Некоторые реализации также поддерживают подключения к узлам в оверлейных сетях, таких как Yggdrasil.
Переменная задержка
Несмотря на то, что основные первоначальные усилия I2P были направлены на коммуникацию с низкой задержкой, система была разработана с учетом сервисов с переменной задержкой с самого начала. На самом базовом уровне приложения, работающие поверх I2P, могут обеспечить анонимность коммуникации со средней и высокой задержкой, при этом по-прежнему смешивая свои шаблоны трафика с трафиком низкой задержки. Однако внутренне I2P может предложить собственную коммуникацию со средней и высокой задержкой через garlic encryption — указывая, что сообщение должно быть отправлено после определенной задержки, в определенное время, после прохождения определенного количества сообщений или с использованием другой стратегии микширования. При многослойном шифровании только router, которому clove открыл запрос на задержку, будет знать, что сообщение требует высокой задержки, что позволяет трафику еще больше смешиваться с трафиком низкой задержки. Как только предварительное условие передачи выполнено, router, удерживающий clove (который сам, скорее всего, будет garlic-сообщением), просто пересылает его по запросу — на router, в tunnel или, скорее всего, к удаленному клиентскому назначению.
Цель переменной задержки сервисов требует значительных ресурсов для механизмов промежуточного хранения и пересылки для её поддержки. Эти механизмы могут поддерживаться и поддерживаются в различных приложениях обмена сообщениями, таких как i2p-bote. На сетевом уровне альтернативные сети, такие как Freenet, предоставляют эти сервисы. Мы решили не заниматься этой целью на уровне I2P router.
Похожие системы
Архитектура I2P основана на концепциях промежуточного программного обеспечения, ориентированного на обработку сообщений, топологии распределённых хеш-таблиц (DHT), анонимности и криптографии свободно маршрутизируемых микснетов, а также адаптивности сетей с коммутацией пакетов. Ценность заключается не в новизне концепций или алгоритмов, а в тщательной разработке, объединяющей результаты исследований существующих систем и научных работ. Хотя существует несколько аналогичных проектов, заслуживающих рассмотрения как с технической, так и с функциональной точки зрения, здесь особо выделяются два из них — Tor и Freenet.
См. также страницу сравнения сетей . Обратите внимание, что эти описания были написаны jrandom в 2003 году и могут быть неточными на данный момент.
Tor
На первый взгляд, Tor и I2P имеют много функциональных сходств, связанных с анонимностью. Хотя разработка I2P началась до того, как мы узнали о ранних усилиях по созданию Tor, многие уроки оригинального onion routing и усилий ZKS были интегрированы в дизайн I2P. Вместо построения по сути доверенной, централизованной системы с серверами каталогов, I2P имеет самоорганизующуюся сетевую базу данных, где каждый узел берет на себя ответственность за профилирование других router’ов, чтобы определить, как лучше использовать доступные ресурсы. Еще одно ключевое отличие заключается в том, что хотя и I2P, и Tor используют многослойные и упорядоченные пути (tunnel’ы и circuits/streams), I2P по своей сути является сетью с коммутацией пакетов, в то время как Tor по сути является сетью с коммутацией каналов, что позволяет I2P прозрачно маршрутизировать в обход перегрузок или других сетевых сбоев, работать с избыточными путями и балансировать нагрузку данных по доступным ресурсам. В то время как Tor предлагает полезную функциональность outproxy, предлагая интегрированное обнаружение и выбор outproxy, I2P оставляет такие решения уровня приложений самим приложениям, работающим поверх I2P — фактически, I2P даже вынес саму TCP-подобную библиотеку потоков на уровень приложений, позволяя разработчикам экспериментировать с различными стратегиями, используя свои специфические знания предметной области для обеспечения лучшей производительности.
С точки зрения анонимности существует много общего при сравнении основных сетей. Однако есть несколько ключевых различий. При работе с внутренним противником или большинством внешних противников, симплексные tunnel I2P раскрывают в два раза меньше данных трафика, чем дуплексные схемы Tor, при простом анализе самих потоков — HTTP-запрос и ответ будут следовать по одному и тому же пути в Tor, в то время как в I2P пакеты, составляющие запрос, будут передаваться через один или несколько исходящих tunnel, а пакеты, составляющие ответ, будут возвращаться через один или несколько других входящих tunnel. Хотя стратегии выбора и упорядочивания узлов I2P должны достаточно эффективно противодействовать атакам предшественника, если потребуется переход к двунаправленным tunnel, мы могли бы просто построить входящий и исходящий tunnel вдоль одних и тех же router.
Еще одна проблема анонимности возникает при использовании в Tor телескопического создания туннелей, поскольку простой подсчет пакетов и измерения времени при прохождении ячеек в цепи через узел противника раскрывает статистическую информацию о том, где противник находится в цепи. I2P использует однонаправленное создание туннелей с одним сообщением, чтобы эти данные не раскрывались. Защита позиции в туннеле важна, поскольку иначе противник смог бы осуществить серию мощных атак типа предшественника, пересечения и подтверждения трафика.
В целом, Tor и I2P дополняют друг друга в своем фокусе — Tor работает над предоставлением высокоскоростного анонимного выхода в Интернет через прокси, в то время как I2P работает над предоставлением децентрализованной устойчивой сети как таковой. В теории, обе системы могут использоваться для достижения обеих целей, но учитывая ограниченные ресурсы разработки, у каждой есть свои сильные и слабые стороны. Разработчики I2P рассматривали шаги, необходимые для модификации Tor с целью использования преимуществ архитектуры I2P, но опасения относительно жизнеспособности Tor в условиях дефицита ресурсов предполагают, что архитектура коммутации пакетов I2P сможет более эффективно использовать ограниченные ресурсы.
Freenet
Freenet сыграл большую роль в начальных этапах разработки I2P — продемонстрировав жизнеспособность активного псевдонимного сообщества, полностью содержащегося внутри сети, и показав, что опасностей, присущих внешним прокси, можно избежать. Первое зерно I2P зародилось как замена коммуникационного уровня для Freenet, с попыткой выделить сложности масштабируемой, анонимной и безопасной связи точка-точка из сложностей устойчивого к цензуре распределенного хранилища данных. Однако со временем некоторые проблемы анонимности и масштабируемости, присущие алгоритмам Freenet, прояснили, что фокус I2P должен оставаться строго на предоставлении универсального анонимного коммуникационного уровня, а не как компонента Freenet. За годы разработчики Freenet пришли к пониманию слабостей в старом дизайне, что побудило их предложить необходимость «премикс» уровня для обеспечения существенной анонимности. Другими словами, Freenet нуждается в работе поверх mixnet, такой как I2P или Tor, где «клиентские узлы» запрашивают и публикуют данные через mixnet к «серверным узлам», которые затем получают и хранят данные согласно эвристическим алгоритмам распределенного хранения данных Freenet.
Функциональность Freenet очень дополняет функциональность I2P, поскольку Freenet изначально предоставляет множество инструментов для работы систем со средней и высокой задержкой, в то время как I2P изначально предоставляет mix-сеть с низкой задержкой, подходящую для обеспечения адекватной анонимности. Логика разделения mixnet от устойчивого к цензуре распределенного хранилища данных по-прежнему кажется самоочевидной с точки зрения инженерии, анонимности, безопасности и распределения ресурсов, поэтому, надеюсь, команда Freenet продолжит усилия в этом направлении, если не просто повторно использует (или поможет улучшить, при необходимости) существующие mixnet, такие как I2P или Tor.
Приложение A: Прикладной уровень
Сам I2P на самом деле не делает много — он просто отправляет сообщения на удаленные назначения и получает сообщения, предназначенные для локальных назначений — большая часть интересной работы происходит на уровнях выше него. Сам по себе I2P можно рассматривать как анонимный и безопасный IP-уровень, а входящую в комплект библиотеку потоков — как реализацию анонимного и безопасного TCP-уровня поверх него. Помимо этого, I2PTunnel предоставляет универсальную систему TCP-проксирования для входа в сеть I2P или выхода из неё, а также различные сетевые приложения обеспечивают дополнительную функциональность для конечных пользователей.
Библиотека потокового вещания
Библиотека потокового вещания I2P может рассматриваться как универсальный интерфейс потокового вещания (аналогичный TCP-сокетам), и реализация поддерживает протокол скользящего окна с несколькими оптимизациями для учета высокой задержки в I2P. Отдельные потоки могут настраивать максимальный размер пакета и другие параметры, хотя значение по умолчанию в 4КБ сжатых данных представляется разумным компромиссом между затратами пропускной способности на повторную передачу потерянных сообщений и задержкой множественных сообщений.
Кроме того, учитывая относительно высокую стоимость последующих сообщений, протокол библиотеки потоковой передачи для планирования и доставки сообщений был оптимизирован, чтобы позволить отдельным передаваемым сообщениям содержать как можно больше доступной информации. Например, небольшая HTTP-транзакция, проксируемая через библиотеку потоковой передачи, может быть завершена за один круговой обмен — первое сообщение объединяет SYN, FIN и небольшую полезную нагрузку (HTTP-запрос обычно помещается), а ответ объединяет SYN, FIN, ACK и небольшую полезную нагрузку (многие HTTP-ответы помещаются). Хотя дополнительный ACK должен быть передан, чтобы сообщить HTTP-серверу о получении SYN/FIN/ACK, локальный HTTP-прокси может немедленно доставить полный ответ в браузер.
В целом, однако, библиотека потоковой передачи во многом напоминает абстракцию TCP, с её скользящими окнами, алгоритмами контроля перегрузки (как медленный старт, так и избежание перегрузки) и общим поведением пакетов (ACK, SYN, FIN, RST и т.д.).
Библиотека именования и адресная книга
Для получения дополнительной информации см. страницу Именование и адресная книга .
Разработано: mihi, Ragnarok
Именование в I2P было часто обсуждаемой темой с самого начала, с сторонниками по всему спектру возможностей. Однако, учитывая присущую I2P потребность в безопасной связи и децентрализованной работе, традиционная система именования в стиле DNS явно исключена, как и системы голосования “большинство решает”. Вместо этого I2P поставляется с универсальной библиотекой именования и базовой реализацией, разработанной для работы с локальным сопоставлением имен к destination, а также с дополнительным приложением под названием “Address Book”. Address book — это основанная на сети доверия безопасная, распределенная и читаемая человеком система именования, жертвующая только требованием глобальной уникальности всех читаемых человеком имен, требуя лишь локальной уникальности. Хотя все сообщения в I2P криптографически адресуются по их destination, разные люди могут иметь локальные записи в address book для “Alice”, которые ссылаются на разные destination. Люди все еще могут обнаруживать новые имена, импортируя опубликованные address book пользователей, указанных в их сети доверия, добавляя записи, предоставленные через третью сторону, или (если некоторые люди организуют серию опубликованных address book, используя систему регистрации “первый пришел — первый получил”) люди могут выбрать рассматривать эти address book как серверы имен, эмулируя традиционную DNS.
I2P не поощряет использование DNS-подобных сервисов, поскольку ущерб от захвата сайта может быть огромным — а небезопасные пункты назначения не имеют ценности. DNSsec сам по себе всё ещё полагается на регистраторов и центры сертификации, тогда как в I2P запросы, отправленные к пункту назначения, не могут быть перехвачены или подменены, поскольку они шифруются открытыми ключами пункта назначения, а сам пункт назначения представляет собой просто пару открытых ключей и сертификат. DNS-подобные системы, с другой стороны, позволяют любому из серверов имён на пути поиска осуществлять простые атаки отказа в обслуживании и подмены. Добавление сертификата, аутентифицирующего ответы как подписанные каким-либо централизованным центром сертификации, решило бы многие проблемы враждебных серверов имён, но оставило бы открытыми атаки повтора, а также атаки враждебных центров сертификации.
Система именования на основе голосования также опасна, особенно учитывая эффективность атак Сибил в анонимных системах — злоумышленник может просто создать произвольно большое количество узлов и “голосовать” каждым из них, чтобы захватить конкретное имя. Методы proof-of-work могут использоваться для того, чтобы создание идентичности не было бесплатным, но по мере роста сети нагрузка, требуемая для связи с каждым участником для проведения онлайн-голосования, становится неосуществимой, или если запрос не охватывает всю сеть, могут быть получены различные наборы ответов.
Как и в случае с Интернетом, I2P выносит проектирование и работу системы именования за пределы коммуникационного уровня (аналогичного IP). Входящая в комплект библиотека именования включает простой интерфейс поставщика услуг, к которому могут подключаться альтернативные системы именования, позволяя конечным пользователям выбирать предпочитаемые компромиссы в именовании.
I2PTunnel
Разработано: mihi
I2PTunnel — это, вероятно, самое популярное и универсальное клиентское приложение I2P, позволяющее осуществлять универсальное проксирование как в сеть I2P, так и из неё. I2PTunnel можно рассматривать как четыре отдельных приложения для проксирования — “client”, который принимает входящие TCP-соединения и перенаправляет их к заданному I2P destination, “httpclient” (также известный как “eepproxy”), который действует как HTTP-прокси и перенаправляет запросы к соответствующему I2P destination (после запроса к службе имён, если необходимо), “server”, который принимает входящие I2P streaming-соединения на destination и перенаправляет их к заданному TCP host+port, и “httpserver”, который расширяет функциональность “server”, анализируя HTTP-запросы и ответы для обеспечения более безопасной работы. Также существует дополнительное приложение “socksclient”, но его использование не рекомендуется по причинам, упомянутым ранее.
I2P сам по себе не является сетью outproxy — проблемы анонимности и безопасности, присущие микс-сети, которая перенаправляет данные в микс и из него, заставили разработчиков I2P сосредоточиться на создании анонимной сети, способной удовлетворить потребности пользователей без необходимости во внешних ресурсах. Однако приложение I2PTunnel “httpclient” предоставляет возможность для outproxy — если запрашиваемое имя хоста не заканчивается на “.i2p”, оно выбирает случайное назначение из предоставленного пользователем набора outproxy и перенаправляет запрос к ним. Эти назначения являются просто экземплярами I2PTunnel “server”, запускаемыми добровольцами, которые явно выбрали запуск outproxy — никто не является outproxy по умолчанию, и запуск outproxy не заставляет автоматически других людей проксировать через вас. Хотя outproxy имеют присущие им слабости, они предлагают простое доказательство концепции для использования I2P и обеспечивают некоторую функциональность в рамках модели угроз, которая может быть достаточной для некоторых пользователей.
I2PTunnel обеспечивает работу большинства используемых приложений. “httpserver”, направленный на веб-сервер, позволяет любому запустить свой собственный анонимный веб-сайт (или “I2P Site”) — веб-сервер поставляется вместе с I2P для этой цели, но можно использовать любой веб-сервер. Любой может запустить “client”, направленный на один из анонимно размещенных IRC-серверов, каждый из которых запускает “server”, направленный на их локальный IRCd и обменивающийся данными между IRCd через свои собственные “client” туннели. Конечные пользователи также имеют “client” туннели, направленные на POP3 и SMTP назначения I2Pmail (которые, в свою очередь, являются просто экземплярами “server”, направленными на POP3 и SMTP серверы), а также “client” туннели, направленные на CVS-сервер I2P, что позволяет анонимную разработку. Иногда люди даже запускали “client” прокси для доступа к экземплярам “server”, направленным на NNTP-сервер.
I2PSnark
I2PSnark разработан: jrandom и др., портирован с клиента Snark от mjw
Входящий в состав установки I2P, I2PSnark предлагает простой анонимный BitTorrent-клиент с возможностью работы с несколькими торрентами, предоставляя весь функционал через простой HTML веб-интерфейс.
I2Pmail / Susimail
Разработано: postman, susi23, mastiejaner
I2Pmail — это скорее сервис, чем приложение. Postman предлагает как внутреннюю, так и внешнюю электронную почту с поддержкой POP3 и SMTP через экземпляры I2PTunnel, обращающиеся к серии компонентов, разработанных с mastiejaner, что позволяет людям использовать свои предпочитаемые почтовые клиенты для отправки и получения почты псевдонимно. Однако, поскольку большинство почтовых клиентов раскрывают значительную идентифицирующую информацию, I2P включает в себя веб-клиент susimail от susi23, который был создан специально с учетом потребностей анонимности I2P. Сервис I2Pmail/mail.i2p предлагает прозрачную фильтрацию вирусов, а также предотвращение атак типа «отказ в обслуживании» с помощью квот, усиленных hashcash. Кроме того, каждый пользователь контролирует свою стратегию пакетирования перед доставкой через outproxy mail.i2p, которые отделены от SMTP и POP3 серверов mail.i2p — и outproxy, и inproxy взаимодействуют с SMTP и POP3 серверами mail.i2p через саму сеть I2P, поэтому компрометация этих неанонимных местоположений не дает доступа к почтовым аккаунтам или паттернам активности пользователей.