ПРИМЕЧАНИЕ: Данный документ был изначально написан jrandom в 2003 году. Хотя мы стремимся поддерживать его актуальность, некоторая информация может быть устаревшей или неполной. Разделы о транспорте и криптографии актуальны по состоянию на январь 2025 года.
Введение
I2P — это масштабируемый, самоорганизующийся, устойчивый сетевой уровень с коммутацией пакетов для анонимной связи, на основе которого может работать любое количество различных приложений, заботящихся об анонимности или безопасности. Каждое из этих приложений может делать собственные компромиссы между анонимностью, задержкой и пропускной способностью, не беспокоясь о правильной реализации свободной маршрутизирующей микссети, что позволяет им смешивать свою активность с более крупным множеством пользователей для обеспечения анонимности, уже работающих поверх I2P.
Уже доступные приложения обеспечивают полный спектр типичных интернет-активностей — анонимный веб-серфинг, веб-хостинг, чат, обмен файлами, электронную почту, блоггинг и синдикацию контента, а также несколько других приложений, находящихся в разработке.
- Веб-браузинг: использование любого существующего браузера с поддержкой прокси.
- Чат: IRC и другие протоколы
- Обмен файлами: I2PSnark и другие приложения
- Электронная почта: susimail и другие приложения
- Блог: используя любой локальный веб-сервер или доступные плагины
В отличие от веб-сайтов, размещенных в сетях распространения контента, таких как Freenet или GNUnet , сервисы, размещенные в I2P, полностью интерактивны — здесь есть традиционные поисковые системы веб-стиля, доски объявлений, блоги с возможностью комментирования, сайты на основе баз данных и мосты для запросов к статическим системам типа Freenet без необходимости локальной установки.
Со всеми этими приложениями с поддержкой анонимности I2P выполняет роль промежуточного программного обеспечения, ориентированного на сообщения — приложения указывают, что хотят отправить некоторые данные криптографическому идентификатору (“destination”) и I2P заботится о том, чтобы данные доставились безопасно и анонимно. I2P также включает простую streaming библиотеку, позволяющую анонимным сообщениям 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: “outbound” tunnel отправляют сообщения от создателя tunnel, в то время как “inbound” tunnel доставляют сообщения к создателю tunnel. Комбинирование этих двух tunnel позволяет пользователям отправлять сообщения друг другу. Отправитель («Алиса» на изображении выше) устанавливает outbound tunnel, в то время как получатель («Боб» на изображении выше) создает inbound tunnel. Шлюз inbound tunnel может получать сообщения от любого другого пользователя и будет передавать их до конечной точки («Боб»). Конечная точка outbound tunnel должна будет отправить сообщение далее к шлюзу inbound tunnel. Для этого отправитель («Алиса») добавляет инструкции к своему зашифрованному сообщению. Как только конечная точка outbound tunnel расшифрует сообщение, у неё будут инструкции для пересылки сообщения к правильному inbound шлюзу (шлюзу к «Бобу»).
Третья важная концепция для понимания — это “network database” I2P (или “netDb”) — пара алгоритмов, используемых для обмена метаданными сети. Существует два типа передаваемых метаданных: “routerInfo” и “leaseSets” — routerInfo предоставляет router’ам данные, необходимые для связи с конкретным router’ом (их публичные ключи, транспортные адреса и т.д.), в то время как leaseSet предоставляет router’ам информацию, необходимую для связи с конкретным назначением. leaseSet содержит несколько “lease” (аренд). Каждая из этих lease указывает шлюз tunnel’я, который позволяет достичь конкретного назначения. Полная информация, содержащаяся в lease:
- Входящий шлюз для tunnel, который позволяет достичь определенного назначения.
- Время истечения срока действия tunnel.
- Пара публичных ключей для возможности шифрования сообщений (для отправки через tunnel и достижения назначения).
Сами router отправляют свои routerInfo непосредственно в netDb, в то время как leaseSet отправляются через исходящие туннели (leaseSet необходимо отправлять анонимно, чтобы избежать корреляции router с его leaseSet).
Мы можем объединить вышеперечисленные концепции для построения успешных соединений в сети.
Чтобы построить собственные входящие и исходящие tunnel, Алиса выполняет поиск в netDb для сбора routerInfo. Таким образом, она собирает списки узлов, которые может использовать в качестве промежуточных хопов в своих tunnel. Затем она может отправить сообщение построения первому хопу, запрашивая создание tunnel и просить этот router переслать сообщение построения дальше, пока tunnel не будет построен.
Когда Алиса хочет отправить сообщение Бобу, она сначала выполняет поиск в netDb, чтобы найти leaseSet Боба, получая его текущие шлюзы входящих туннелей. Затем она выбирает один из своих исходящих туннелей и отправляет сообщение по нему с инструкциями для конечной точки исходящего туннеля переслать сообщение одному из шлюзов входящих туннелей Боба. Когда конечная точка исходящего туннеля получает эти инструкции, она пересылает сообщение как требуется, а когда шлюз входящего туннеля Боба получает его, оно пересылается по туннелю к маршрутизатору Боба. Если Алиса хочет, чтобы Боб мог ответить на сообщение, ей нужно явно передать свой собственный пункт назначения как часть самого сообщения. Это можно сделать, введя слой более высокого уровня, что выполняется в библиотеке streaming . Алиса также может сократить время ответа, прикрепив свой последний LeaseSet к сообщению, чтобы Бобу не нужно было выполнять поиск в netDb, когда он захочет ответить, но это необязательно.
Хотя сами tunnel имеют многослойное шифрование для предотвращения несанкционированного раскрытия узлам внутри сети (как и транспортный уровень делает это для предотвращения несанкционированного раскрытия узлам вне сети), необходимо добавить дополнительный сквозной уровень шифрования, чтобы скрыть сообщение от конечной точки исходящего tunnel и шлюза входящего tunnel. Это “garlic encryption ” позволяет router Алисы упаковать несколько сообщений в одно “garlic-сообщение”, зашифрованное определенным публичным ключом, чтобы промежуточные узлы не могли определить ни количество сообщений внутри garlic, ни содержание этих сообщений, ни место назначения отдельных частей. Для типичного сквозного общения между Алисой и Бобом garlic будет зашифрован публичным ключом, опубликованным в leaseSet Боба, что позволяет зашифровать сообщение без раскрытия публичного ключа собственному router Боба.
Еще один важный факт, который следует помнить, заключается в том, что I2P полностью основан на сообщениях и что некоторые сообщения могут быть потеряны по пути. Приложения, использующие I2P, могут использовать интерфейсы, ориентированные на сообщения, и самостоятельно заботиться о своих потребностях в управлении перегрузкой и надежности, но большинству из них лучше всего подойдет повторное использование предоставленной библиотеки streaming для представления I2P как сети, основанной на потоках.
Tunnel’ы
И входящие, и исходящие туннели работают по схожим принципам. Шлюз туннеля накапливает определённое количество сообщений туннеля, в конечном итоге предварительно обрабатывая их во что-то пригодное для доставки через туннель. Затем шлюз шифрует эти предварительно обработанные данные и пересылает их на первый узел. Этот узел и последующие участники туннеля добавляют слой шифрования после проверки того, что это не дубликат, перед пересылкой на следующий узел. В конце концов, сообщение прибывает в конечную точку, где сообщения снова разделяются и пересылаются по запросу. Разница заключается в том, что делает создатель туннеля — для входящих туннелей создатель является конечной точкой и просто расшифровывает все добавленные слои, в то время как для исходящих туннелей создатель является шлюзом и заранее расшифровывает все слои, чтобы после добавления всех слоёв пошагового шифрования сообщение прибыло в открытом виде в конечную точку туннеля.
Выбор конкретных узлов для передачи сообщений, а также их определенный порядок важны для понимания как анонимности I2P, так и характеристик производительности. В то время как network database (ниже) имеет свои собственные критерии для выбора узлов для запросов и хранения записей, создатели туннелей могут использовать любые узлы в сети в любом порядке (и даже любое количество раз) в одном туннеле. Если бы идеальные данные о задержке и пропускной способности были известны глобально, выбор и упорядочивание определялись бы конкретными потребностями клиента в сочетании с их моделью угроз. К сожалению, данные о задержке и пропускной способности не тривиально собирать анонимно, а зависимость от недоверенных узлов для предоставления этой информации имеет свои серьезные последствия для анонимности.
С точки зрения анонимности, самым простым методом было бы случайно выбрать узлы из всей сети, расположить их в случайном порядке и использовать эти узлы в том же порядке вечно. С точки зрения производительности, самым простым методом было бы выбрать самые быстрые узлы с необходимой свободной пропускной способностью, распределив нагрузку между разными узлами для обеспечения прозрачного переключения при отказах, и перестраивать tunnel всякий раз, когда изменяется информация о пропускной способности. В то время как первый подход является хрупким и неэффективным, второй требует недоступной информации и обеспечивает недостаточную анонимность. Вместо этого I2P работает над предоставлением ряда стратегий выбора узлов в сочетании с кодом измерений, учитывающим анонимность, для организации узлов по их профилям.
В качестве основы I2P постоянно профилирует узлы, с которыми взаимодействует, измеряя их косвенное поведение — например, когда узел отвечает на запрос netDb за 1,3 секунды, эта задержка приема-передачи записывается в профили всех router’ов, участвующих в двух tunnel’ах (входящем и исходящем), через которые прошли запрос и ответ, а также в профиль запрашиваемого узла. Прямые измерения, такие как задержка транспортного уровня или перегрузка, не используются как часть профиля, поскольку ими можно манипулировать и они могут быть связаны с измеряющим router’ом, подвергая его тривиальным атакам. При сборе этих профилей выполняется серия вычислений для каждого из них, чтобы обобщить его производительность — задержку, способность обрабатывать большое количество активности, перегружен ли он в данный момент и насколько хорошо он интегрирован в сеть. Затем эти вычисления сравниваются для активных узлов, чтобы организовать router’ы в четыре уровня — быстрые и высокопроизводительные, высокопроизводительные, не отказывающие и отказывающие. Пороговые значения для этих уровней определяются динамически, и хотя в настоящее время используются довольно простые алгоритмы, существуют альтернативы.
Используя данные этого профиля, самой простой разумной стратегией выбора узлов является случайный выбор узлов из верхнего уровня (быстрые и высокопроизводительные), и эта стратегия в настоящее время применяется для клиентских tunnel. Разведывательные tunnel (используемые для netDb и управления tunnel) случайно выбирают узлы из уровня “не отказывающих” (который включает также router из ‘лучших’ уровней), позволяя узлу более широко исследовать router, фактически оптимизируя выбор узлов через рандомизированный hill climbing . Однако эти стратегии сами по себе допускают утечку информации о узлах верхнего уровня router через атаки сбора предшественников и netDb. В свою очередь, существует несколько альтернатив, которые, хотя и не балансируют нагрузку так же равномерно, будут противостоять атакам, проводимым определенными классами противников.
Выбирая случайный ключ и упорядочивая peers согласно их XOR расстоянию от него, утечка информации снижается при predecessor и harvesting атаках в соответствии с частотой отказов peers и оборотом tier. Другая простая стратегия для борьбы с netDb harvesting атаками — просто зафиксировать входные tunnel gateway(s), но рандомизировать peers дальше в tunnels. Для борьбы с predecessor атаками от противников, которых контактирует клиент, конечные точки исходящих tunnels также должны оставаться фиксированными. Выбор того, какой peer зафиксировать в наиболее уязвимой точке, конечно, должен иметь ограничение по продолжительности, поскольку все peers в конечном итоге выходят из строя, поэтому это может быть либо реактивно скорректировано, либо проактивно предотвращено для имитации измеренного среднего времени между отказами других routers. Эти две стратегии могут, в свою очередь, быть объединены, используя фиксированный уязвимый peer и XOR-основанное упорядочивание внутри самих tunnels. Более жесткая стратегия зафиксировала бы точных peers и упорядочивание потенциального tunnel, используя отдельных peers только в том случае, если все они согласны участвовать одинаковым образом каждый раз. Это отличается от XOR-основанного упорядочивания тем, что predecessor и successor каждого peer всегда одинаковы, в то время как XOR только гарантирует, что их порядок не изменяется.
Как упоминалось ранее, I2P в настоящее время (релиз 0.8) включает вышеописанную многоуровневую случайную стратегию с упорядочиванием на основе XOR. Более подробное обсуждение механики работы tunnel, управления и выбора узлов можно найти в спецификации tunnel .
Network Database (netDb)
Как упоминалось ранее, netDb в I2P работает для распределения метаданных сети. Это подробно описано на странице база данных сети , но основное объяснение приведено ниже.
Все I2P router содержат локальную 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): Начальная загрузка netDb довольно проста. Как только router удается получить один routerInfo доступного узла, он может запросить у этого router ссылки на другие router’ы в сети. В настоящее время ряд пользователей публикуют свои файлы routerInfo на веб-сайте, чтобы сделать эту информацию доступной. I2P автоматически подключается к одному из этих веб-сайтов для сбора файлов routerInfo и начальной загрузки. I2P называет этот процесс начальной загрузки “пересевом” (reseeding).
Масштабируемость поиска: Поиск в сети I2P является итеративным, а не рекурсивным. Если поиск от floodfill не удался, поиск будет повторен к следующему ближайшему floodfill. Floodfill не запрашивает рекурсивно данные у другого floodfill. Итеративный поиск масштабируется для больших DHT-сетей.
Транспортные протоколы
Связь между router’ами должна обеспечивать конфиденциальность и целостность против внешних злоумышленников, одновременно подтверждая, что contacted router является тем, кто должен получить данное сообщение. Детали того, как router’ы общаются с другими router’ами, не являются критичными — три различных протокола использовались в разное время для обеспечения этих базовых потребностей.
I2P в настоящее время поддерживает два транспортных протокола: NTCP2 через TCP и SSU2 через UDP. Они заменили предыдущие версии протоколов NTCP и SSU , которые теперь считаются устаревшими. Оба протокола поддерживают как IPv4, так и IPv6. Благодаря поддержке транспортов как TCP, так и UDP, I2P может эффективно проходить через большинство брандмауэров, включая те, которые предназначены для блокировки трафика в условиях ограничительной цензуры. NTCP2 и SSU2 были разработаны для использования современных стандартов шифрования, улучшения устойчивости к идентификации трафика, повышения эффективности и безопасности, а также для обеспечения более надёжного прохождения NAT. Router’ы публикуют каждый поддерживаемый транспорт и IP-адрес в netDb. Router’ы с доступом к публичным сетям IPv4 и IPv6 обычно публикуют четыре адреса — по одному для каждой комбинации NTCP2/SSU2 с IPv4/IPv6.
SSU2 поддерживает и расширяет цели SSU. SSU2 имеет много общего с другими современными протоколами на основе UDP, такими как Wireguard и QUIC. Помимо надёжной передачи сетевых сообщений через UDP, SSU2 предоставляет специализированные возможности для одноранговых сетей: совместное обнаружение IP-адресов, определение состояния межсетевого экрана и преодоление NAT. Как описано в спецификации SSU :
Целью данного протокола является обеспечение безопасной, аутентифицированной, полунадежной и неупорядоченной доставки сообщений, раскрывая лишь минимальный объем данных, легко различимых третьими сторонами. Он должен поддерживать высокоинтенсивную связь, а также TCP-дружественное управление перегрузкой и может включать обнаружение PMTU. Он должен быть способен эффективно передавать большие объемы данных со скоростями, достаточными для домашних пользователей. Кроме того, он должен поддерживать методы преодоления сетевых препятствий, таких как большинство NAT или брандмауэров.
NTCP2 поддерживает и расширяет цели NTCP. Он обеспечивает эффективную и полностью зашифрованную передачу сетевых сообщений по TCP, а также устойчивость к идентификации трафика, используя современные стандарты шифрования.
I2P поддерживает несколько транспортов одновременно. Конкретный транспорт для исходящего соединения выбирается с помощью “ставок”. Каждый транспорт делает ставку на соединение, и относительное значение этих ставок определяет приоритет. Транспорты могут отвечать разными ставками в зависимости от того, существует ли уже установленное соединение с узлом.
Значения ставок (приоритета) зависят от реализации и могут варьироваться в зависимости от условий трафика, количества подключений и других факторов. Роутеры также публикуют свои предпочтения транспорта для входящих подключений в сетевой базе данных как транспортные “стоимости” для каждого транспорта и адреса.
Криптография
I2P использует криптографию на нескольких уровнях протокола для шифрования, аутентификации и верификации. Основными уровнями протокола являются: транспорты, сообщения построения tunnel, шифрование уровня tunnel, сообщения базы данных сети и сквозные (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 от различных противников. На самом низком уровне межмаршрутизаторная связь защищена безопасностью транспортного уровня. Сообщения туннелей , передаваемые по транспортам, имеют собственное многоуровневое шифрование. Различные другие сообщения передаются внутри “garlic messages”, которые также зашифрованы.
Garlic сообщения
Garlic сообщения являются расширением “луковичного” многослойного шифрования, позволяющим содержимому одного сообщения включать несколько “зубчиков” — полностью сформированные сообщения вместе с их собственными инструкциями для доставки. Сообщения упаковываются в garlic сообщение всякий раз, когда сообщение иначе проходило бы в открытом виде через узел, который не должен иметь доступ к информации — например, когда router хочет попросить другой router участвовать в tunnel, они упаковывают запрос внутрь garlic, шифруют этот garlic открытым ключом принимающего router и пересылают его через tunnel. Другой пример — когда клиент хочет отправить сообщение получателю — router отправителя упакует это сообщение с данными (вместе с некоторыми другими сообщениями) в garlic, зашифрует этот garlic открытым ключом, опубликованным в leaseSet получателя, и переправит его через соответствующие tunnel.
“Инструкции”, прикрепленные к каждому сегменту внутри слоя шифрования, включают возможность запросить переадресацию сегмента локально, на удаленный router или в удаленный tunnel на удаленном router. В этих инструкциях есть поля, позволяющие узлу запросить задержку доставки до определенного времени или выполнения условия, хотя они не будут выполняться до развертывания нетривиальных задержек . Можно явно маршрутизировать garlic-сообщения через любое количество переходов без построения tunnel, или даже перенаправлять tunnel-сообщения, обернув их в garlic-сообщения и переадресовав на несколько переходов перед доставкой к следующему переходу в 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-байтовых nonce. В следующий раз, когда отправитель хочет зашифровать garlic-сообщение для другого router’а, вместо ElGamal-шифрования нового сессионного ключа он просто выбирает один из ранее доставленных session tags и шифрует полезную нагрузку AES как прежде, используя сессионный ключ, который использовался с этим session tag, добавляя сам session tag в начало. Когда router получает garlic-зашифрованное сообщение, он проверяет первые 32 байта, чтобы увидеть, соответствуют ли они доступному session tag — если да, то он просто расшифровывает сообщение AES, но если нет, то расшифровывает первый блок ElGamal.
Каждый тег сессии может быть использован только один раз, чтобы предотвратить ненужную корреляцию различных сообщений внутренними противниками как передаваемых между одними и теми же маршрутизаторами. Отправитель сообщения, зашифрованного ElGamal/AES+SessionTag, выбирает, когда и сколько тегов доставить, заранее снабжая получателя достаточным количеством тегов для покрытия серии сообщений. Garlic сообщения могут обнаружить успешную доставку тега, объединяя небольшое дополнительное сообщение как часть (clove) — “сообщение о статусе доставки”. Когда garlic сообщение прибывает к предназначенному получателю и успешно расшифровывается, это небольшое сообщение о статусе доставки является одной из раскрытых частей и содержит инструкции для получателя отправить эту часть обратно первоначальному отправителю (через входящий tunnel, разумеется). Когда первоначальный отправитель получает это сообщение о статусе доставки, он знает, что теги сессии, объединённые в garlic сообщение, были успешно доставлены.
Сами теги сессии имеют очень короткое время жизни, после чего они отбрасываются, если не используются. Кроме того, количество сохраняемых тегов для каждого ключа ограничено, как и количество самих ключей — если их поступает слишком много, могут быть отброшены как новые, так и старые сообщения. Отправитель отслеживает, проходят ли сообщения с использованием тегов сессии, и если связь недостаточна, он может отбросить те, которые ранее считались правильно доставленными, возвращаясь к полному дорогостоящему шифрованию ElGamal.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags требовал существенных накладных расходов по ряду направлений. Использование процессора было высоким, поскольку ElGamal довольно медленный. Пропускная способность была избыточной из-за того, что большое количество меток сессии должно было доставляться заранее, а также из-за того, что открытые ключи ElGamal очень большие. Использование памяти было высоким из-за требования хранить большие объемы меток сессии. Надежность страдала от потери доставки меток сессии.
ECIES-X25519-AEAD-Ratchet был разработан для решения этих проблем. X25519 используется для обмена ключами. ChaCha20/Poly1305 используется для аутентифицированного симметричного шифрования. Ключи шифрования “двойного ratchet” или ротируются периодически. Session tags уменьшены с 32 байт до 8 байт и генерируются с помощью PRNG. Протокол имеет много сходств с signal protocol, используемым в Signal и WhatsApp. Этот протокол обеспечивает значительно меньшие накладные расходы на процессор, оперативную память и пропускную способность.
Теги сессии генерируются из детерминированного синхронизированного PRNG, работающего на обеих концах сессии для создания тегов сессии и ключей сессии. PRNG представляет собой HKDF с использованием SHA-256 HMAC и инициализируется из результата X25519 DH. Теги сессии никогда не передаются заранее; они включаются только вместе с сообщением. Получатель хранит ограниченное количество ключей сессии, проиндексированных по тегу сессии. Отправителю не нужно хранить никаких тегов сессии или ключей, поскольку они не отправляются заранее; они могут генерироваться по требованию. Поддерживая этот PRNG приблизительно синхронизированным между отправителем и получателем (получатель предварительно вычисляет окно следующих, например, 50 тегов), устраняются накладные расходы на периодическое объединение большого количества тегов.
Будущее
Протоколы I2P эффективны на большинстве платформ, включая мобильные телефоны, и безопасны для большинства моделей угроз. Однако есть несколько областей, которые требуют дальнейшего улучшения для удовлетворения потребностей тех, кто сталкивается с мощными противниками, спонсируемыми государством, и для противостояния угрозам постоянного развития криптографии и постоянно растущей вычислительной мощности. Две возможные функции, restricted routes и variable latency, были предложены jrandom в 2003 году. Хотя мы больше не планируем реализовывать эти функции, они описаны ниже.
Работа с ограниченными маршрутами
I2P — это оверлейная сеть, предназначенная для работы поверх функционирующей сети с коммутацией пакетов, использующая принцип «от конца к концу» для обеспечения анонимности и безопасности. Хотя Интернет больше не полностью придерживается принципа «от конца к концу» (из-за использования NAT), I2P требует, чтобы значительная часть сети была доступна — на краях может находиться некоторое количество пиров, работающих с ограниченными маршрутами, но I2P не включает подходящий алгоритм маршрутизации для вырожденного случая, когда большинство пиров недоступно. Однако она могла бы работать поверх сети, использующей такой алгоритм.
Работа с ограниченными маршрутами, где существуют пределы того, какие узлы доступны напрямую, имеет несколько различных функциональных и анонимностных последствий, в зависимости от того, как обрабатываются ограниченные маршруты. На самом базовом уровне ограниченные маршруты существуют, когда узел находится за NAT или межсетевым экраном, который не разрешает входящие соединения. Это было в значительной степени решено путем интеграции распределенного пробивания отверстий в транспортный уровень, что позволяет людям за большинством NAT и межсетевых экранов получать незапрашиваемые соединения без какой-либо конфигурации. Однако это не ограничивает раскрытие IP-адреса узла для router’ов внутри сети, поскольку они могут просто быть представлены узлу через опубликованный introducer.
Помимо функциональной обработки ограниченных маршрутов, существует два уровня ограниченной работы, которые можно использовать для ограничения раскрытия своего IP-адреса — использование специфичных для router’а tunnel’ей для связи и предоставление ‘клиентских router’ов’. В первом случае router’ы могут либо создать новый пул tunnel’ей, либо повторно использовать свой исследовательский пул, публикуя входящие шлюзы некоторых из них как часть своей routerInfo вместо своих транспортных адресов. Когда peer хочет связаться с ними, он видит эти шлюзы tunnel’ей в netDb и просто отправляет соответствующее сообщение им через один из опубликованных tunnel’ей. Если peer за ограниченным маршрутом хочет ответить, он может сделать это либо напрямую (если готов раскрыть свой IP peer’у), либо косвенно через свои исходящие tunnel’и. Когда router’ы, с которыми peer имеет прямые соединения, хотят связаться с ним (например, для пересылки сообщений tunnel’ей), они просто отдают приоритет своему прямому соединению над опубликованным шлюзом tunnel’я. Концепция ‘клиентских router’ов’ просто расширяет ограниченный маршрут, не публикуя никаких адресов router’а. Такому router’у даже не нужно было бы публиковать свою routerInfo в netDb, достаточно предоставлять свою самоподписанную routerInfo peer’ам, с которыми он связывается (необходимо для передачи публичных ключей 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 или, скорее всего, к удаленному пункту назначения клиента.
Цель обеспечения сервисов с переменной задержкой требует значительных ресурсов для механизмов store-and-forward (сохранения и пересылки) для их поддержки. Эти механизмы могут поддерживаться и поддерживаются в различных приложениях для обмена сообщениями, таких как 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 — доказав жизнеспособность активного псевдонимного сообщества, полностью существующего внутри сети, и продемонстрировав, что опасностей, присущих outproxy, можно избежать. Первое зерно I2P возникло как замещающий коммуникационный слой для Freenet, пытаясь выделить сложности масштабируемой, анонимной и безопасной связи точка-точка из сложностей устойчивого к цензуре распределенного хранилища данных. Однако со временем некоторые проблемы анонимности и масштабируемости, присущие алгоритмам Freenet, прояснили, что фокус I2P должен оставаться строго на предоставлении универсального анонимного коммуникационного слоя, а не как компонента Freenet. За годы разработчики Freenet пришли к пониманию слабостей старого дизайна, что побудило их предложить использование слоя “premix” для обеспечения существенной анонимности. Иными словами, Freenet должна работать поверх mixnet, такой как I2P или Tor, где “клиентские узлы” запрашивают и публикуют данные через mixnet к “серверным узлам”, которые затем получают и сохраняют данные согласно эвристическим алгоритмам распределенного хранения данных Freenet.
Функциональность Freenet очень хорошо дополняет функциональность I2P, поскольку Freenet изначально предоставляет множество инструментов для работы систем со средней и высокой задержкой, в то время как I2P изначально предоставляет mix-сеть с низкой задержкой, подходящую для обеспечения адекватной анонимности. Логика разделения mixnet от устойчивого к цензуре распределённого хранилища данных по-прежнему кажется самоочевидной с точки зрения инженерии, анонимности, безопасности и распределения ресурсов, поэтому, надеюсь, команда Freenet продолжит усилия в этом направлении, если не просто переиспользует (или поможет улучшить, при необходимости) существующие mixnet, такие как I2P или Tor.
Приложение А: Прикладной уровень
Сам I2P на самом деле не делает много — он просто отправляет сообщения к удалённым адресатам и получает сообщения, предназначенные для локальных адресатов — большая часть интересной работы происходит на уровнях выше него. Сам по себе I2P можно рассматривать как анонимный и безопасный IP-уровень, а входящую в комплект библиотеку потоков как реализацию анонимного и безопасного TCP-уровня поверх него. Помимо этого, I2PTunnel предоставляет универсальную систему TCP-проксирования для входа в сеть I2P или выхода из неё, а также множество сетевых приложений обеспечивают дополнительную функциональность для конечных пользователей.
Библиотека потокового вещания
Библиотеку потокового вещания I2P можно рассматривать как универсальный интерфейс потокового вещания (аналогичный TCP-сокетам), и реализация поддерживает протокол скользящего окна с несколькими оптимизациями для учета высокой задержки в сети I2P. Отдельные потоки могут настраивать максимальный размер пакета и другие параметры, хотя значение по умолчанию в 4KB сжатых данных кажется разумным компромиссом между затратами пропускной способности на повторную передачу потерянных сообщений и задержкой множественных сообщений.
Кроме того, учитывая относительно высокую стоимость последующих сообщений, протокол библиотеки потокового соединения для планирования и доставки сообщений был оптимизирован, чтобы позволить отдельным передаваемым сообщениям содержать как можно больше доступной информации. Например, небольшая 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” (адресная книга). Адресная книга представляет собой безопасную, распределенную и человекочитаемую систему именования, основанную на сети доверия, жертвуя лишь требованием глобальной уникальности всех человекочитаемых имен, требуя только локальной уникальности. Хотя все сообщения в I2P криптографически адресуются по их destination, разные люди могут иметь локальные записи в адресной книге для “Alice”, которые ссылаются на разные destination. Люди все еще могут обнаруживать новые имена, импортируя опубликованные адресные книги узлов, указанных в их сети доверия, добавляя записи, предоставленные третьей стороной, или (если некоторые люди организуют серию опубликованных адресных книг, используя систему регистрации “кто первый пришел, тот первый получил”) люди могут выбрать рассматривать эти адресные книги как серверы имен, эмулируя традиционный DNS.
I2P не поощряет использование DNS-подобных сервисов, поскольку ущерб от захвата сайта может быть огромным — а небезопасные назначения не имеют ценности. DNSsec сам по себе всё ещё полагается на регистраторов и центры сертификации, в то время как в I2P запросы, отправленные к назначению, не могут быть перехвачены, а ответ подделан, поскольку они зашифрованы публичными ключами назначения, а само назначение представляет собой просто пару публичных ключей и сертификат. DNS-подобные системы, напротив, позволяют любому из серверов имён на пути поиска осуществлять простые атаки типа отказ в обслуживании и спуфинга. Добавление сертификата, аутентифицирующего ответы как подписанные некоторым централизованным центром сертификации, решило бы многие проблемы враждебных серверов имён, но оставило бы открытыми атаки повтора, а также атаки враждебных центров сертификации.
Именование в стиле голосования также опасно, особенно учитывая эффективность атак Сибилы в анонимных системах — злоумышленник может просто создать произвольно большое количество узлов и “голосовать” каждым из них, чтобы захватить конкретное имя. Методы proof-of-work могут использоваться для того, чтобы создание идентичности не было бесплатным, но по мере роста сети нагрузка, необходимая для обращения к каждому участнику для проведения онлайн-голосования, становится неосуществимой, или если не опрашивается вся сеть, могут быть получены различные наборы ответов.
Однако, как и в случае с Интернетом, I2P выносит проектирование и функционирование системы имен за пределы коммуникационного уровня (подобного IP). Встроенная библиотека именования включает простой интерфейс поставщика услуг, к которому могут подключаться альтернативные системы именования, позволяя конечным пользователям выбирать предпочтительные компромиссы в именовании.
I2PTunnel
Разработано: mihi
I2PTunnel является, вероятно, самым популярным и универсальным клиентским приложением I2P, позволяющим осуществлять общее проксирование как внутрь, так и из сети I2P. I2PTunnel можно рассматривать как четыре отдельных прокси-приложения — «клиент», который принимает входящие TCP-соединения и перенаправляет их в указанное I2P destination, «httpclient» (также известный как «eepproxy»), который действует как HTTP-прокси и перенаправляет запросы соответствующему I2P destination (после запроса к службе имен при необходимости), «сервер», который принимает входящие I2P streaming-соединения на destination и перенаправляет их на указанный TCP хост+порт, и «httpserver», который расширяет функции «сервера» путем разбора HTTP-запросов и ответов для обеспечения более безопасной работы. Существует также дополнительное приложение «socksclient», но его использование не рекомендуется по причинам, упомянутым ранее.
I2P сам по себе не является сетью outproxy — проблемы анонимности и безопасности, присущие mix-сети, которая пересылает данные в mix и из него, привели к тому, что дизайн I2P сосредоточен на предоставлении анонимной сети, способной удовлетворить потребности пользователей без необходимости во внешних ресурсах. Однако приложение I2PTunnel “httpclient” предоставляет возможность для outproxy — если запрашиваемое имя хоста не заканчивается на “.i2p”, оно выбирает случайное назначение из предоставленного пользователем набора outproxy и пересылает запрос к ним. Эти назначения являются просто экземплярами I2PTunnel “server”, запускаемыми добровольцами, которые явно выбрали запуск outproxy — никто не является outproxy по умолчанию, и запуск outproxy не говорит автоматически другим людям проксировать через вас. Хотя outproxy действительно имеют присущие им слабости, они предлагают простое доказательство концепции использования I2P и обеспечивают некоторую функциональность в рамках модели угроз, которая может быть достаточной для некоторых пользователей.
I2PTunnel обеспечивает работу большинства используемых приложений. “httpserver”, указывающий на веб-сервер, позволяет любому запустить свой собственный анонимный веб-сайт (или “I2P Site”) — веб-сервер входит в комплект I2P для этой цели, но можно использовать любой веб-сервер. Любой может запустить “client”, указывающий на один из анонимно размещенных IRC-серверов, каждый из которых запускает “server”, указывающий на свой локальный IRCd и обменивающийся данными между IRCd через собственные “client” tunnel. Конечные пользователи также имеют “client” tunnel, указывающие на POP3 и SMTP назначения I2Pmail (которые, в свою очередь, являются просто экземплярами “server”, указывающими на POP3 и SMTP серверы), а также “client” tunnel, указывающие на 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, поэтому компрометация этих неанонимных местоположений не дает доступа к почтовым аккаунтам или шаблонам активности пользователя.