Предложения по I2P on I2P - Проект невидимого интернета

'Флаг' Зашифрованного' Потока

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается добавления флага к потоковой передаче, который указывает тип используемого сквозного шифрования.

Мотивация

Высоко нагруженные приложения могут столкнуться с нехваткой тэгов ElGamal/AES+SessionTags.

Конструкция

Добавьте новый флаг где-то в рамках протокола потоковой передачи. Если пакет приходит с этим флагом, это означает, что полезная нагрузка зашифрована AES с использованием ключа из частного ключа и открытого ключа пира. Это позволило бы исключить чесночное (ElGamal/AES) шифрование и проблему нехватки тэгов.

Может быть установлен на пакет или весь поток через SYN.

B32 для зашифрованных LS2

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

В сети идет развертывание и тестирование. Возможны незначительные изменения. Смотрите SPEC для официальной спецификации.

Обзор

Стандартные адреса Base 32 (“b32”) содержат хеш от места назначения. Это не работает для зашифрованных ls2 (предложение 123).

Вы не можете использовать традиционный адрес base 32 для зашифрованного LS2 (предложение 123), поскольку он содержит только хеш от пункта назначения. Он не предоставляет незаслепленный открытый ключ. Клиенты должны знать открытый ключ пункта назначения, тип подписи, тип подписи для заслепления и необязательный секретный или приватный ключ, чтобы получить и расшифровать leaseset. Таким образом, одного адреса base 32 недостаточно. Клиенту необходимо или полное назначение (которое содержит открытый ключ), или сам открытый ключ. Если у клиента есть полное назначение в адресной книге, и книга поддерживает обратный поиск по хешу, то открытый ключ может быть получен.

BEP9 Восстановление Информации

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение о добавлении полного восстановления информации в реализацию BEP9 для I2P.

Мотивация

BEP9 не отправляет весь торрент-файл, теряя таким образом несколько важных элементов словаря и изменяя общий SHA1 торрент-файлов. Это плохо для maggot-ссылок и плохо, потому что теряется важная информация. Списки трекеров, комментарии и любые дополнительные данные исчезают. Способ восстановления этой информации важен и должен добавить как можно меньше в торрент-файл. Также он не должен зависеть от чего-либо циклически. Информация для восстановления не должна влиять на текущих клиентов никаким образом. Торренты, которые не имеют трекера (URL трекера буквально ’trackerless’), не содержат этого дополнительного поля, так как специфичны для использования протокола maggot для обнаружения и загрузки, который изначально не теряет информацию.

ECIES Tunnels

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Сетевое развертывание и тестирование в процессе. Возможны незначительные правки. См. SPEC для официальной спецификации.

Обзор

В этом документе предлагаются изменения шифрования сообщений создания туннеля с использованием криптографических примитивов, введенных ECIES-X25519 . Это часть общего предложения Предложение 156 по переходу маршрутизаторов с ElGamal на ключи ECIES-X25519.

Для целей перехода сети с ElGamal + AES256 на ECIES + ChaCha20 необходимы туннели со смешанными узлами ElGamal и ECIES. Предоставлены спецификации обработки прыжков в смешанных туннелях. Никаких изменений в формат, обработку или шифрование прыжков ElGamal вноситься не будет.

ECIES роутеры

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Развертывание и тестирование сети в процессе. Может быть изменено. Статус:

ECIES роутеры реализованы в 0.9.48, см. Common .
Создание туннелей реализовано в 0.9.48, см. Tunnel-Creation-ECIES .
Зашифрованные сообщения для ECIES роутеров реализованы в 0.9.49, см. ECIES-ROUTERS .
Сообщения о создании новых туннелей реализованы в 0.9.51.

Обзор

Резюме

Идентификаторы роутеров в настоящее время содержат ключ шифрования ElGamal. Это стандарт с начала I2P. ElGamal медленен и требует замены во всех местах использования.

Предложения для LS2 Prop123 и ECIES-X25519-AEAD-Ratchet Prop144 (теперь определены в ECIES ) описали замену ElGamal на ECIES для Destinations.

ECIES-P256

Mon, 01 Jan 0001 00:00:00 +0000

Мотивация

ECIES-P256 значительно быстрее, чем ElGamal. Существуют несколько eepsites i2pd с типом крипто ECIES-P256, и Java должна быть способна общаться с ними и наоборот. i2pd поддерживает это с версии 2.16.0 (0.9.32 Java).

Обзор

Предложение вводит новый тип крипто ECIES-P256, который может появляться в части сертификата идентификации или как отдельный тип ключа шифрования в LeaseSet2. Может использоваться в RouterInfo, LeaseSet1 и LeaseSet2.

Местоположения ключей ElGamal

Для обзора, Публичные ключи ElGamal размером 256 байт можно найти в следующих структурах данных. Смотрите спецификацию общих структур.

ECIES-X25519-AEAD-Ratchet

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Развертывание и тестирование сети в процессе. Возможны незначительные правки. См. SPEC для официальной спецификации.

Следующие функции не реализованы по состоянию на 0.9.46:

Блоки MessageNumbers, Options и Termination
Ответы на уровне протокола
Нулевой статический ключ
Мультикаст

Обзор

Это предложение по первому новому типу сквозного шифрования с момента начала I2P, заменяющему ElGamal/AES+SessionTags Elg-AES .

Оно опирается на предыдущую работу следующим образом:

Спецификация общих структур Common Structures
Спецификация I2NP включая LS2
ElGamal/AES+Session Tags Elg-AES
http://zzz.i2p/topics/1768 обзор новой асимметричной криптографии
Обзор низкоуровневой криптографии CRYPTO-ELG
ECIES http://zzz.i2p/topics/2418
NTCP2 Proposal 111
123 Новые записи в netDB
142 Новый шаблон криптографии
Noise протокол
Алгоритм двойного зажима Signal

Цель — поддержка нового шифрования для сквозной, коммуникации от пункта назначения до пункта назначения.

I2PControl API 2

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение описывает API2 для I2PControl.

Это предложение было отклонено и не будет реализовано, так как нарушает обратную совместимость. См. ссылку на обсуждение в теме для деталей.

Внимание разработчикам!

Все RPC параметры теперь будут в нижнем регистре. Это нарушит обратную совместимость с реализациями API1. Причина этого - предоставление пользователям API версии >=API2 самой простой и последовательной API.

Спецификация API 2

{
 "id": "id",
 "method": "method_name",
 "params": {
 "token": "auth_token",
 "method_param": "method_parameter_value",
 },
 "jsonrpc": "2.0"
 }

 {
 "id": "id",
 "result": "result_value",
 "jsonrpc": "2.0"
 }

Параметры

"id"

LeaseSet 2

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается нового формата LeaseSet с поддержкой новых типов шифрования.

Мотивация

Сквозная криптография, используемая в туннелях I2P, имеет отдельные ключи для шифрования и подписи. Ключи подписи находятся в Destination туннеля, который уже был расширен с помощью KeyCertificates для поддержки новых типов подписей. Однако, ключи шифрования являются частью LeaseSet, который не содержит сертификатов. Поэтому необходимо реализовать новый формат LeaseSet и добавить поддержку его хранения в netDb.

Положительным моментом является то, что как только LS2 будет реализован, все существующие Destinations смогут использовать более современные типы шифрования; роутеры, которые могут получить и прочитать LS2, будут гарантированно иметь поддержку всех типов шифрования, введенных вместе с ним.

Multipath TCP для потоковой передачи

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается расширения потоковой передачи для использования нескольких туннелей на соединение, аналогично multipath TCP.

Мотивация

Клиентские туннели используются библиотекой потоковой передачи в достаточно стандартной манере TCP.

Было бы предпочтительнее разрешить решение, подобное multipath TCP, где клиентские туннели используются на основе индивидуальных характеристик, таких как:

Задержка
Пропускная способность
Доступность

Дизайн

TBD

NTCP 2

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Фаза предложения закрыта. Смотрите SPEC для официальной спецификации. Это предложение может быть использовано для справочной информации.

Обзор

В этом предложении описывается протокол аутентифицированного согласования ключей, призванный повысить устойчивость NTCP к различным формам автоматической идентификации и атак.

Предложение организовано следующим образом: сначала представлены цели безопасности, затем обсуждается базовый протокол. Далее приводится полная спецификация всех сообщений протокола. Наконец, рассматриваются адреса маршрутизаторов и идентификация версий. Также включено приложение, посвящённое общей атаке на распространённые схемы дополнения, и приложение с рядом кандидатов на аутентифицированный шифр.

PT Transport

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение по созданию транспортного средства для I2P, которое подключается к другим маршрутизаторам через подключаемые транспорты (Pluggable Transports).

Мотивация

Подключаемые транспорты (PTs) были разработаны для Tor как способ модульного добавления транспортов для обфускации к мостам Tor.

I2P уже имеет модульную транспортную систему, которая снижает барьер для добавления альтернативных транспортов. Добавление поддержки PTs предоставило бы I2P простой способ экспериментов с альтернативными протоколами и подготовку к сопротивлению блокировкам.

Проектирование

Существует несколько потенциальных уровней реализации:

Quasi DNS

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение заключается в использовании DNS через датаграммы для поддоменов.

Мотивация

Будет определено

Разработка

Будет определено

Спецификация

Будет определено

Миграция

Будет определено

RedDSA-BLAKE2b-Ed25519

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение добавляет новый тип подписи, использующий BLAKE2b-512 с персонализированными строками и солями, для замены SHA-512. Это исключит три класса возможных атак.

Мотивация

В ходе обсуждений и разработки NTCP2 (предложение 111) и LS2 (предложение 123), мы кратко рассмотрели различные возможные атаки и способы их предотвращения. Три из этих атак — это атаки расширения длины, межпротокольные атаки и идентификация дублирующихся сообщений.

Для NTCP2 и LS2 мы решили, что эти атаки не имели прямого отношения к рассматриваемым предложениям, и любые решения противоречили цели минимизации новых примитивов. Также мы определили, что скорость хеш-функций в этих протоколах не являлась важным фактором в наших решениях. Поэтому мы в основном отложили решение до отдельного предложения. Хотя мы добавили некоторые функции персонализации в спецификацию LS2, мы не потребовали каких-либо новых хеш-функций.

RI и Дополнение Destination

Mon, 01 Jan 0001 00:00:00 +0000

Статус

Реализовано в версии 0.9.57.
Оставляем это предложение открытым, чтобы мы могли улучшать и обсуждать идеи из раздела «Планирование на будущее».

Обзор

Краткое содержание

Открытый ключ ElGamal в Destination не используется с версии 0.6 (2005).
Хотя в наших спецификациях действительно указано, что он не используется, в них НЕ указано, что реализации могут не генерировать пару ключей ElGamal и просто заполнять это поле случайными данными.

Мы предлагаем изменить спецификации, указав, что
поле игнорируется и реализации МОГУТ заполнять его случайными данными.
Это изменение обратно совместимо. Неизвестно ни одной реализации, которая проверяла бы открытый ключ ElGamal.

SSU2

Mon, 01 Jan 0001 00:00:00 +0000

Status

Rollout plan:

Feature	Testing (not default)	Enabled by default
Local test code	2022-02
Joint test code	2022-03
Joint test in-net	0.9.54 2022-05
Freeze basic protocol	0.9.54 2022-05
Basic Session	0.9.55 2022-08	0.9.56 2022-11
Address Validation (Retry)	0.9.55 2022-08	0.9.56 2022-11
Fragmented RI in handshake	0.9.55 2022-08	0.9.56 2022-11
New Token	0.9.55 2022-08	0.9.57 2022-11
Freeze extended protocol	0.9.55 2022-08
Relay	0.9.55 2022-08	0.9.56 2022-11
Peer Test	0.9.55 2022-08	0.9.56 2022-11
Enable for random 2%	0.9.55 2022-08
Path Validation	0.9.55+ dev	0.9.56 2022-11
Connection Migration	0.9.55+ dev	0.9.56 2022-11
Immediate ACK flag	0.9.55+ dev	0.9.56 2022-11
Key Rotation	0.9.57 2023-02	0.9.58 2023-05
Disable SSU 1 (i2pd)	0.9.56 2022-11
Disable SSU 1 (Java I2P)	0.9.58 2023-05	0.9.61 2023-12
Basic Session includes the handshake and data phase. Extended protocol includes relay and peer test.

Overview

This proposal describes an authenticated key agreement protocol to improve the resistance of SSU to various forms of automated identification and attacks.

TLS Транспорт

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается внедрения транспорта на основе TLS.

Мотивация

Это часто предлагается — иметь устойчивый к перехвату транспорт, чтобы мы могли противостоять отпечаткам и блокировке со стороны интернет-провайдеров и государственных противников, как это реализовано в Tor (т.е. пытается выглядеть как сессия HTTPS в Firefox).

Дизайн

TBD

UDP-трекеры

Mon, 01 Jan 0001 00:00:00 +0000

Статус

Одобрено на проверке 2025-06-24. Спецификация находится в UDP спецификации . Реализовано в zzzot 0.20.0-beta2. Реализовано в i2psnark начиная с API 0.9.67. Проверьте документацию других реализаций для получения информации о статусе.

Обзор

Данное предложение касается реализации UDP-трекеров в I2P.

Change History

Предварительное предложение по UDP tracker’ам в I2P было опубликовано на нашей странице спецификации bittorrent в мае 2014 года; это было до нашего формального процесса предложений, и оно так и не было реализовано. Данное предложение было создано в начале 2022 года и упрощает версию 2014 года.

Блоклист в новостной ленте

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Данное предложение заключается в распространении обновлений блоклиста в файле новостей, который распространяется в подписанном формате su3. Реализовано в 0.9.28.

Мотивация

Без этого обновление блоклиста происходит только в новом выпуске. Используются существующая подписка на новости. Этот формат может быть использован в различных реализациях роутеров, но только Java роутер сейчас использует подписку на новости.

Дизайн

Добавить новый раздел в файл news.xml. Позволяет блокировать по IP или хэшу роутера. У раздела будет собственная временная метка. Позволяет разблокировать ранее заблокированные записи.

Большие I2NP Сообщения

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение о увеличении предела размера для I2NP сообщений.

Мотивация

Использование iMule датаграмм размером 12KB выявило множество проблем. Фактический предел сегодня ближе к 10KB.

Проектирование

Что следует сделать:

Увеличить предел NTCP - не так просто?
Больше настроек количества сессионных тегов. Может повлиять на максимальный размер окна? Есть ли статистика для анализа? Сделать количество переменным в зависимости от того, сколько они считают нужным? Могут ли они запрашивать больше? запрашивать количество?

Двунаправленные туннели

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение о реализации двунаправленных туннелей в I2P.

Мотивация

i2pd собирается ввести двунаправленные туннели, которые будут строиться только через другие роутеры i2pd на данный момент. Для сети они будут выглядеть как обычные входящие и исходящие туннели.

Дизайн

Цели

Уменьшить использование сети и ЦПУ за счет сокращения количества сообщений TunnelBuild
Возможность немедленно узнать, если участник исчез
Более точное профилирование и статистика
Использование других даркнетов в качестве промежуточных узлов

Изменения туннелей

TunnelBuild

Диапазон портов в Routerinfo

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Или список вместо одного порта.

Клиент может подключиться к любому из них и должен выбирать случайным образом. Это сделает схему трафика менее распознаваемой, поможет обойти DPI и некоторые фильтры анти-DDoS.

Также может быть использовано для распределения нагрузки на очень загруженные узлы в будущем.

Мотивация

TBD

Дизайн

TBD

Спецификация

TBD

Миграция

TBD

Доставка OBEP в 1-of-N или N-of-N туннели

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

В данном предложении рассматриваются два улучшения для повышения производительности сети:

Передача выбора IBGW в OBEP путем предоставления ему списка альтернатив вместо одного варианта.
Включение маршрутизации мультикаст-пакетов на уровне OBEP.

Мотивация

В случае прямого соединения идея заключается в снижении перегрузки соединений за счёт предоставления OBEP гибкости при подключении к IBGW. Возможность указывать несколько туннелей также позволяет реализовать мультикаст на уровне OBEP (путём доставки сообщения во все указанные туннели).

Альтернативой части предложения, касающейся делегирования, было бы использование хэша LeaseSet, аналогично существующей возможности указания хэша целевой RouterIdentity . Это привело бы к уменьшению размера сообщения и потенциально более свежему LeaseSet. Однако:

Записи служб в LS2

Mon, 01 Jan 0001 00:00:00 +0000

Статус

Утверждено на втором рассмотрении 2025-04-01; спецификации обновлены; реализация ещё не выполнена.

Обзор

В I2P отсутствует централизованная система DNS.
Однако адресная книга в сочетании с системой имён b32 позволяет
маршрутизатору выполнять поиск полных назначений и получать наборы лизингов (lease sets), содержащие
список шлюзов и ключей, чтобы клиенты могли подключиться к этому назначению.

Таким образом, leaseSet’ы похожи на DNS-записи. Однако в настоящее время нет механизма
определения, поддерживает ли хост какие-либо службы, либо на этом назначении, либо на другом,
аналогично DNS-записям SRV , определённым в RFC 2782 .

Заслепление ключей ECDSA

Mon, 01 Jan 0001 00:00:00 +0000

Мотивация

Некоторым людям не нравятся EdDSA или RedDSA. Мы должны предложить некоторые альтернативы и позволить им заслеплять подписи ECDSA.

Обзор

Это предложение описывает заслепление ключей для типов подписей ECDSA 1, 2, 3.

Предложение

Работает так же, как RedDSA, но все в формате Big Endian. Разрешены только одинаковые типы подписей, например, 1->1, 2->2, 3->3.

Определения

B Базовая точка кривой

L Порядок группы эллиптической кривой. Свойство кривой.

DERIVE_PUBLIC(a) Преобразование закрытого ключа в открытый путем умножения B на эллиптической кривой

Зашифрованный LeaseSet

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение посвящено переработке механизма шифрования LeaseSets.

Мотивация

Текущий шифрованный LS ужасен и не безопасен. Я могу это сказать, поскольку я сам diseñ и реализовал его.

Причины:

Шифрование с использованием AES CBC
Одный ключ AES для всех
Сроки истечения аренды по-прежнему открыты
Открытый ключ шифрования по-прежнему открыт

Дизайн

Цели

Сделать всю систему непрозрачной
Ключи для каждого получателя

Стратегия

Сделать как в GPG/OpenPGP. Асимметрично зашифровать симметричный ключ для каждого получателя. Данные расшифровываются с помощью этого асимметричного ключа. См. например RFC-4880-S5.1 , если мы сможем найти алгоритм, который небольшой и быстрый.

Каталог Услуг

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается протокола, который приложения могут использовать для регистрации и поиска услуг в каталоге.

Мотивация

Самый прямолинейный способ поддержки onioncat — через каталог услуг.

Это похоже на предложение, которое Sponge сделал некоторое время назад на IRC. Я не думаю, что он его оформил, но его идея заключалась в том, чтобы разместить его в netDb. Я не сторонник этого, но обсуждение лучшего метода доступа к каталогу (поиски по netDb, DNS-over-i2p, HTTP, hosts.txt и т.д.) я оставлю на другой день.

Команды для подписки на адресную книгу

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Развертывание в сети завершено. См. SPEC для официальной спецификации.

Обзор

Это предложение касается расширения фида подписки на адрес с командами, чтобы позволить серверам имен транслировать обновления записей от владельцев хостов. Реализовано в версии 0.9.26.

Мотивация

В настоящее время серверы подписки hosts.txt просто отправляют данные в формате hosts.txt, который выглядит следующим образом:

example.i2p=b64destination

Есть несколько проблем с этим:

Владельцы доменных имен не могут обновить назначение, связанное с их доменными именами (например, чтобы обновить ключ подписи на более сильный тип).
Владельцы доменных имен не могут произвольно отказаться от своих доменных имен; они должны передать соответствующие приватные ключи назначения новому владельцу.
Нет способа аутентификации поддомена как контролируемого соответствующим базовым именем хоста; в настоящее время это контролируется индивидуально на некоторых серверах имен.

Дизайн

Это предложение добавляет ряд командных строк в формат hosts.txt. С этими командами серверы имен могут расширять свои услуги для предоставления ряда дополнительных функций. Клиенты, которые реализуют это предложение, смогут прослушивать эти функции через обычный процесс подписки.

Меньшие Сообщения Построения Туннеля

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Реализовано в версии API 0.9.51. Выполняется внедрение и тестирование в сети. Подлежит незначительным изменениям. См. I2NP и Tunnel-Creation-ECIES для окончательной спецификации.

Обзор

Резюме

Текущий размер зашифрованных записей запроса и ответа на создание туннеля составляет 528 байт. Для типичных сообщений Variable Tunnel Build и Variable Tunnel Build Reply общий размер составляет 2113 байт. Это сообщение разбивается на три 1KB туннельных сообщения для обратного пути.

Изменения в формате записи размером 528 байт для маршрутизаторов ECIES-X25519 специфицированы в Prop152 и Tunnel-Creation-ECIES . Для комбинации маршрутизаторов ElGamal и ECIES-X25519 в туннеле размер записи должен оставаться 528 байт. Однако если все маршрутизаторы в туннеле являются ECIES-X25519, возможна новая, меньшая запись построения, так как шифрование ECIES-X25519 имеет значительно меньший оверхед, чем ElGamal.

Мета-LeaseSet для мультирейтинга

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Данное предложение касается реализации поддержки настоящего мультирейтинга в I2P, который может масштабироваться до больших сайтов.

Мотивация

Мультирейтинг является временным решением и, предположительно, не будет работать, например, для facebook.i2p в масштабах. Предположим, у нас есть 100 мультидомов, каждый из которых имеет 16 туннелей, это 1600 публикаций LS каждые 10 минут, или почти 3 в секунду. Floodfills будут перегружены, и запустятся ограничения. И это еще до того, как мы упомянем трафик поиска.

Мульткаст

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Основная идея: Отправить одну копию через ваш исходящий туннель, конечная точка в исходящем туннеле распределяет ко всем входным шлюзам. Сквозное шифрование исключено.

Дизайн

Новый тип сообщения мульткаст-туннеля (тип доставки = 0x03)
Конечная точка исходящего туннеля распределяет мульткаст
Новый тип сообщения I2NP для мульткаста?
Новый тип сообщения I2CP Multicast SendMessageMessage
Не шифровать между маршрутизаторами в OutNetMessageOneShotJob (чеснок?)

Приложение:

RTSP-прокси?

Streamr:

Настройка MTU? Или сделать это просто в приложении?
Прием и передача по запросу

Невидимое мультихоминг

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

В этом предложении описывается проект протокола, позволяющего клиенту I2P, сервису или внешнему процессу балансировки управлять несколькими маршрутизаторами, прозрачно размещающими одну и ту же Destination .

На данный момент предложение не определяет конкретную реализацию. Оно может быть реализовано как расширение I2CP , либо как новый протокол.

Мотивация

Мультихоминг — это использование нескольких маршрутизаторов для размещения одной и той же Destination. Текущий способ мультихоминга в I2P — это запуск одной и той же Destination на каждом маршрутизаторе независимо; маршрутизатор, который будет использоваться клиентами в конкретный момент времени, — это тот, который последним опубликовал LeaseSet.

Новые записи netDB

Mon, 01 Jan 0001 00:00:00 +0000

Статус

Части этого предложения завершены и реализованы в версиях 0.9.38 и 0.9.39.
Общие структуры, I2CP, I2NP и другие спецификации
обновлены, чтобы отразить поддерживаемые изменения.

Завершённые части всё ещё могут быть подвергнуты незначительным изменениям.
Другие части предложения всё ещё находятся в разработке
и могут быть существенно пересмотрены.

Поиск сервисов (типы 9 и 11) имеет низкий приоритет,
не запланирован и может быть вынесен в отдельное предложение.

Обзор

Это обновление и объединение следующих 4 предложений:

Новый шаблон предложения по шифрованию

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

В этом документе описываются важные вопросы, которые необходимо учитывать при предложении замены или добавления к нашей асимметричной криптографии на основе ElGamal.

Это информационный документ.

Мотивация

ElGamal устарел и медленен, и существуют лучшие альтернативы.
Однако перед тем, как добавить или перейти на любой новый алгоритм, необходимо решить несколько вопросов.
В этом документе освещаются эти нерешённые проблемы.

Предварительное исследование

Любой, кто предлагает новую криптографию, должен быть знаком с нижеследующими документами:

Предложение 111 NTCP2
Предложение 123 LS2
Предложение 136 экспериментальные типы подписей
Предложение 137 опциональные типы подписей
Темы обсуждений для каждого из вышеперечисленных предложений, ссылки на которые находятся внутри
Приоритеты предложений 2018 года
Предложение ECIES
Обзор новой асимметричной криптографии
Обзор низкоуровневой криптографии

Использование асимметричной криптографии

Напомним, что ElGamal используется нами для:

Обновления потоковой передачи

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Роутеры Java I2P и i2pd старше API 0.9.58 (выпущенного в марте 2023) уязвимы перед атакой повторной передачи пакетa SYN. Это проблема в проектировании протокола, а не ошибка реализации.

Пакеты SYN подписываются, но подпись начального пакета SYN, отправленного от Алисы Бобу, не привязана к идентичности Боба, поэтому Боб может сохранить и повторно передать этот пакет, отправив его жертве Чарли. Чарли подумает, что пакет пришел от Алисы и ответит ей. В большинстве случаев это безвредно, но пакет SYN может содержать начальные данные (такие как GET или POST), которые Чарли обработает немедленно.

Обфускация NTCP

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается модернизации транспорта NTCP для улучшения его устойчивости к автоматической идентификации.

Мотивация

Данные NTCP шифруются после первого сообщения (и первое сообщение выглядит как случайные данные), что предотвращает идентификацию протокола через “анализ полезной нагрузки”. Однако он все еще уязвим к идентификации протокола через “анализ потока”. Это связано с тем, что первые 4 сообщения (т.е. рукопожатие) имеют фиксированную длину (288, 304, 448 и 48 байт).

Добавив случайное количество случайных данных в каждое из сообщений, мы можем значительно усложнить задачу.

Ограничения перегрузки

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Добавить индикаторы перегрузки в опубликованную информацию о маршрутизаторе (RI).

Мотивация

Ограничения пропускной способности “caps” (возможности) указывают на лимиты общего потока и доступность, но не на состояние перегрузки. Индикатор перегрузки поможет маршрутизаторам избегать попыток строить каналы через загруженный маршрутизатор, что способствует дополнительным перегрузкам и снижению успешности построения туннелей.

Дизайн

Определить новые caps для указания различных уровней перегрузки или проблем с пропускной способностью. Эти показатели будут находиться в верхнем уровне RI caps, а не в address caps.

Ограниченные Маршруты

Mon, 01 Jan 0001 00:00:00 +0000

Введение

Мысли

Добавьте новый транспорт “IND” (косвенный), который публикует хэш leaseSet в структуре RouterAddress: “IND: [key=aababababababababb]”. Этот транспорт делает ставку на наименьший приоритет, когда целевой маршрутизатор его публикует. Для отправки данным транспортом, получите leaseset от однорангового узла как обычно и отправьте его непосредственно на lease.
Одноранговый узел, рекламирующий IND, должен построить и поддерживать набор туннелей к другому одноранговому узлу. Это не исследовательские туннели и не клиентские туннели, а второй набор маршрутизаторных туннелей.

Опции сообщения о создании туннеля

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Это предложение не было реализовано в указанном виде, однако длинные и короткие сообщения о создании ECIES (предложения 152 и 157) были разработаны с полями расширяемых опций. См. спецификацию Tunnel Creation ECIES для официальной спецификации.

Обзор

Добавить гибкий, расширяемый механизм для опций в записях создания туннеля I2NP, которые содержатся в сообщениях о создании туннеля и ответах на создание туннеля.

Мотивация

Появляются несколько предварительных, не задокументированных предложений по установке опций или конфигурации в сообщении о создании туннеля, так что создатель туннеля может передать некоторые параметры каждому узлу туннеля.

Пакетная обработка нескольких данных гвоздиков в Garlic

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается отправки нескольких Data Garlic Cloves внутри конечного Garlic Message, вместо одного.

Мотивация

Не ясно.

Необходимые изменения

Изменения будут внесены в OCMOSJ и связанные вспомогательные классы, а также в ClientMessagePool. Так как очереди сейчас нет, потребуется новая очередь и некоторая задержка. Любая пакетная обработка должна учитывать максимальный размер garlic, чтобы минимизировать потери. Возможно, 3KB? Для начала нужно инструментировать вещи, чтобы измерить, как часто это будет использоваться.

Мысли

Неясно, будет ли это иметь какое-либо полезное воздействие, поскольку потоковая передача уже выполняет пакетную обработку и выбирает оптимальное MTU. Пакетная обработка увеличила бы размер сообщения и вероятность его выпадения по экспоненте.

Параметры пропускной способности туннеля

Mon, 01 Jan 0001 00:00:00 +0000

ПРИМЕЧАНИЕ

Это предложение было одобрено и теперь входит в Tunnel Creation ECIES specification с API 0.9.65. Пока что известные реализации отсутствуют; даты внедрения / версии API TBD.

Обзор

Поскольку мы увеличили производительность сети за последние несколько лет с помощью новых протоколов, типов шифрования и улучшений управления перегрузками, стали возможны более быстрые приложения, такие как потоковое видео. Эти приложения требуют высокой пропускной способности на каждом шаге в их клиентских туннелях.

Однако участвующие маршрутизаторы не имеют информации о том, сколько пропускной способности будет использовать туннель, когда они получают сообщение о создании туннеля. Они могут только принять или отклонить туннель на основе текущей общей пропускной способности, используемой всеми участвующими туннелями, и общего лимита пропускной способности для участвующих туннелей.

Перевод имени для GarliCat

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение о добавлении поддержки обратных DNS-запросов к I2P.

Текущий механизм перевода имени

GarliCat (GC) выполняет перевод имени для установки соединений с другими GC узлами. Этот перевод имени представляет собой перекодировку двоичного представления адреса в форму кодирования Base32. Таким образом, перевод работает в обе стороны.

Эти адреса выбраны длиной 80 бит. Это связано с тем, что Tor использует 80-битные значения для адресации своих скрытых услуг. Таким образом, OnionCat (который является GC для Tor) работает с Tor без дополнительного вмешательства.

Плата за бездействие для записей в адресной книге

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Если адрес находится в офлайне длительное время, он должен быть удален из адресной книги, и имя становится доступным для новой регистрации. Так работает inr сейчас.

Но что, если владелец больше не заинтересован в поддержке этого ресурса, но хочет сохранить адрес для себя, чтобы избежать мошенничества и т. д. Необходимо ввести ежегодную плату. Адрес останется в книгах, как только она будет оплачена. Плата больше не требуется, если ресурс снова в сети. В случае со stats.i2p деньги должны идти в бюджет I2P.

Поддержка Floodfill для дополнительных типов подписей

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Добавить способ для floodfill узлов рекламировать поддержку дополнительных типов подписей. Это обеспечит возможность поддерживать новые типы подписей в долгосрочной перспективе, даже если не все реализации поддерживают их.

Мотивация

Предложение GOST 134 выявило несколько проблем с ранее неиспользуемым диапазоном экспериментальных типов подписей.

Во-первых, поскольку типы подписей в экспериментальном диапазоне не могут быть зарезервированы, они могут быть использованы одновременно для нескольких типов подписей.

Во-вторых, если информация о маршрутизаторе или набор аренд с экспериментальным типом подписи не может быть сохранен на floodfill, новый тип подписи трудно полностью протестировать или использовать на пробной основе.

Поддержка Floodfill для экспериментальных типов сигнатур

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Для типов сигнатур в экспериментальном диапазоне (65280-65534) floodfills должны принимать netdb stores без проверки сигнатуры.

Это позволит поддерживать тестирование новых типов сигнатур.

Мотивация

Предложение GOST 134 выявило две проблемы с ранее неиспользуемым экспериментальным диапазоном типов сигнатур.

Во-первых, так как типы сигнатур в экспериментальном диапазоне не могут быть зарезервированы, они могут использоваться для нескольких типов сигнатур одновременно.

Во-вторых, если информация о роутере или lease set с экспериментальным типом сигнатуры не может быть сохранена на floodfill, новый тип сигнатуры трудно полностью протестировать или использовать временно.

Поиск в базе данных с параметрами ECIES

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

ECIES к ElG реализовано в 0.9.46, и этап предложения закрыт. См. I2NP для официальной спецификации. На это предложение можно ссылаться для получения фоновой информации. ECIES к ECIES с включенными ключами реализовано с версии 0.9.48. Раздел ECIES-к-ECIES (производные ключи) может быть вновь открыт или включен в будущие предложения.

Обзор

Определения

AEAD: ChaCha20/Poly1305
DLM: Сообщение поиска в базе данных I2NP
DSM: Сообщение хранения в базе данных I2NP
DSRM: Сообщение ответа поиска в базе данных I2NP
ECIES: ECIES-X25519-AEAD-Ratchet (предложение 144)
ElG: ElGamal
ENCRYPT(k, n, payload, ad): как определено в ECIES
LS: Leaseset
lookup: I2NP DLM
reply: I2NP DSM или DSRM

Резюме

При отправке DLM для LS на floodfill, DLM обычно указывает, что ответ должен быть с тегом, зашифрован AES и отправлен по туннелю к месту назначения. Поддержка ответов зашифрованных AES была добавлена в 0.9.7.

Поиск услуг

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это полная, напыщенная, позволяющая всё в netdb предложенная идея. Также известна как anycast. Это будет четвертый предложенный подтип LS2.

Мотивация

Допустим, вы хотите рекламировать своё направление как аутпрокси, или узел GNS, или Tor шлюз, или Bittorrent DHT, или imule, или i2phex, или Seedless начальную загрузку и т.д. Вы могли бы хранить эту информацию в netDB вместо использования отдельного уровня начальной загрузки или информации.

Нет никого, кто бы отвечал, так что, в отличие от массового мультихона, вы не можете иметь подписанный авторитетный список. Поэтому вы могли бы просто опубликовать свою запись на floodfill. Floodfill бы агрегировал эти данные и отправлял их в ответ на запросы.

Помощники адресов с аутентификацией

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение добавляет механизм аутентификации к URL-адресам помощников.

Мотивация

URL-адреса помощников по своей природе небезопасны. Кто угодно может вставить параметр помощника адресу в ссылку, даже для изображения, и может указать любое назначение в параметре URL “i2paddresshelper”. В зависимости от реализации HTTP-прокси пользователя, это отображение имени хоста/назначения, если оно отсутствует в адресной книге, может быть принято, с промежуточным сообщением для подтверждения пользователем или без него.

Дизайн

Доверенные серверы переходов и службы регистрации адресной книги будут предоставлять новые ссылки помощников, добавляющие параметры аутентификации. Два новых параметра будут представлять собой подпись в формате base 64 и строку подписавшего.

Постквантовые криптографические протоколы

Mon, 01 Jan 0001 00:00:00 +0000

Состояние

Протокол / Функция	Статус
Ratchet	Завершено в Java I2P и i2pd
NTCP2	Бета Q1 2026
SSU2	Внедрение начинается в ближайшее время, Бета Q23 2026
MLDSA SigTypes	Низкий приоритет, вероятно 2027+

Обзор

Хотя исследования и конкурс подходящих постквантовых (PQ) криптографических алгоритмов ведутся уже десять лет, выбор стал ясен лишь недавно.

Мы начали изучать последствия PQ криптографии в 2022 году zzz.i2p .

Стандарты TLS добавили поддержку гибридного шифрования за последние два года, и теперь оно используется для значительной части зашифрованного трафика в интернете благодаря поддержке в Chrome и Firefox Cloudflare .

Предложение I2P #165: Исправление SSU2

Mon, 01 Jan 0001 00:00:00 +0000

Предложение от weko, orignal, Anonymous и zzz.

Обзор

Этот документ предлагает изменения в SSU2 после атаки на I2P, которая использовала уязвимости в SSU2. Основная цель - усиление безопасности и предотвращение атак типа отказа в обслуживании (DDoS) и попыток деанонимизации.

Модель угроз

Злоумышленник создает новые фальшивые RI (роутер не существует): это обычный RI, но он указывает адрес, порт, ключи s и i от реального роутера Боба, затем он затапливает сеть. Когда мы пытаемся подключиться к этому (как мы думаем, реальному) роутеру, мы, как Алиса, можем подключиться к этому адресу, но мы не можем быть уверены, что это сделано с помощью реального RI Боба. Это возможно и использовалось для атаки типа отказа в обслуживании (создайте большое количество таких RI и затопите сеть), также это может облегчить атаки деанонимизации путем подставы хороших роутеров и не подставы злоумышленнических роутеров, если мы забаним IP с множеством RI (вместо того чтобы лучше распределить построение туннеля к этим RI как к одному роутеру).

Предложение по I2P №166: Учетная запись/Хост Поддержка типов туннелей

Mon, 01 Jan 0001 00:00:00 +0000

Предложение о введении HTTP-прокси туннеля с учётом хоста

Это предложение направлено на решение проблемы «Общего Идентификатора» при традиционном использовании HTTP через I2P посредством введения нового типа HTTP-прокси туннеля. Данный тип туннеля обладает дополнительным поведением, призванным предотвратить или ограничить возможность отслеживания со стороны потенциально враждебных операторов скрытых сервисов за целевыми пользовательскими агентами (браузерами) и самим клиентским приложением I2P.

Что такое проблема «Общего Идентификатора»?

Проблема «Общего Идентификатора» возникает, когда пользовательский агент в криптографически адресуемой оверлейной сети использует один и тот же криптографический идентификатор с другим пользовательским агентом. Это происходит, например, когда Firefox и GNU Wget настроены на использование одного и того же HTTP-прокси.

Предпочтение ближайших маршрутизаторов в ключевом пространстве

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение по организации пиров таким образом, чтобы они предпочитали подключаться к другим пирами, которые находятся ближе к ним в ключевом пространстве.

Мотивация

Идея заключается в улучшении успешности создания туннеля путем увеличения вероятности, что маршрутизатор уже подключен к другому.

Дизайн

Необходимые изменения

Эти изменения потребуют:

Каждый маршрутизатор предпочитает подключения рядом с ними в ключевом пространстве.
Каждый маршрутизатор должен знать, что каждый маршрутизатор предпочитает подключения рядом с ними в ключевом пространстве.

Преимущества для создания туннелей

Если вы строите туннель:

Проверка ID транспортной сети

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

NTCP2 (предложение 111) не отклоняет подключения с различными ID сетей на этапе запроса сессии. В настоящее время подключение должно быть отклонено на этапе подтверждения сессии, когда Боб проверяет RI Алисы.

Аналогично, SSU не отклоняет подключения с различными ID сетей на этапе запроса сессии. Подключение должно в настоящее время быть отклонено после этапа подтверждения сессии, когда Боб проверяет RI Алисы.

Это предложение изменяет этап запроса сессии для обоих транспортов, чтобы включать ID сети, и делает это обратно совместимым образом.

Протокол Datagram2

Mon, 01 Jan 0001 00:00:00 +0000

Статус

Одобрено на рассмотрении 2025-04-15. Изменения включены в спецификации. Реализовано в Java I2P, начиная с API 0.9.66. Проверьте документацию по реализации для получения информации о статусе.

Обзор

Выделено из Prop123 как отдельное предложение.

Оффлайн подписи не могут быть проверены в процессе обработки датаграмм с возможностью ответа. Необходимо флаг для указания на оффлайн подписанную дату, но нет места для размещения флага.

Потребуется полностью новый номер и формат протокола I2CP, который будет добавлен в спецификацию DATAGRAMS . Назовем его “Datagram2”.

Протокол Garlic Farm

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это спецификация протокола Garlic Farm, основанная на JRaft, его коде “exts” для реализации поверх TCP и примере приложения “dmprinter” JRAFT .

Нам не удалось найти реализацию с документированным сетевым протоколом. Однако реализация JRaft достаточно проста, чтобы мы могли изучить код и задокументировать его протокол. Этот документ — результат этих усилий.

Это будет бэкенд для координации маршрутизаторов, публикующих записи в Meta LeaseSet. См. предложение 123.

Цели

Малый размер кода
Основан на существующей реализации
Без сериализованных Java-объектов или любых Java-специфичных функций или кодировок
Любая загрузка (bootstrapping) находится за рамками спецификации. Предполагается, что хотя бы один другой сервер зашит в код или настроен вне протокола
Поддержка как внеполосных, так и внутри-I2P сценариев использования

Дизайн

Протокол Raft не является конкретным протоколом; он определяет лишь машину состояний. Поэтому мы документируем конкретный протокол JRaft и основываем наш протокол на нём. Единственное изменение по сравнению с протоколом JRaft — добавление рукопожатия с аутентификацией.

Процесс предложений для I2P

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Этот документ описывает, как изменить спецификации I2P, как работают предложения I2P, и связь между предложениями I2P и спецификациями.

Этот документ адаптирован из процесса предложений Tor, и большая часть содержания ниже была первоначально написана Ником Мэтьюсоном.

Это информационный документ.

Мотивация

Ранее наш процесс обновления спецификаций I2P был относительно неформальным: мы делали предложение на форуме разработчиков и обсуждали изменения, затем мы достигали консенсуса и патчили спецификацию с черновыми изменениями (не обязательно в том порядке), и, наконец, мы реализовывали изменения.

Расширение I2PControl

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Данное предложение добавляет новую информацию в API i2pcontrol, обеспечивая большую гибкость. Эта информация включает: добавление, удаление, получение и изменение записей в адресных книгах и скрытых сервисах. Также в рамках данного предложения предоставляется дополнительная информация о вашем маршрутизаторе, например, о пирах, новостях, netDb и другое.

Мотивация

Область применения данного предложения — создание унифицированной и упрощённой консоли маршрутизатора, которую можно использовать во всех реализациях маршрутизаторов со стандартным набором туннелей i2p. По сути, это предложение позволяет обеспечить более интуитивно понятный и удобный пользовательский интерфейс для пользователей по всей сети I2P.

Сбор статистики по выбору

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается автоматизированной системы отчетности для сбора статистики сети по выбору.

Мотивация

В настоящее время существует несколько сетевых параметров, которые были определены на основе обоснованных предположений. Подозревается, что некоторые из них можно настроить для улучшения общей производительности сети с точки зрения скорости, надежности и так далее. Однако изменение их без надлежащих исследований является очень рискованным.

Проектирование

Маршрутизатор поддерживает обширный сбор статистики, который может быть использован для анализа сетевых свойств. Нам нужна автоматизированная система отчетности, которая собирает эти данные в централизованном месте. Естественно, это должно быть на основе выбора, так как это в значительной степени разрушает анонимность. (Статистика, дружественная к конфиденциальности, уже отправляется на stats.i2p) В качестве приближенной оценки, для сети размером 30,000, выборка из 300 репортирующих маршрутизаторов должна быть достаточно представительной.

Сообщение сброса для ElGamal/AES+SessionTags

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение для сообщения I2NP, которое можно использовать для сброса тегов сессии между двумя Адресами.

Мотивация

Представьте, что у какого-то адресата есть куча подтвержденных тегов для другого адресата. Но этот адресат перезагрузился или потерял эти теги другим способом. Первый адресат продолжает отправлять сообщения с тегами, а второй адресат не может расшифровать. Второй адресат должен иметь возможность сказать первому адресату сбросить (начать с нуля) через дополнительный чеснок, таким же образом, как он отправляет обновленный LeaseSet.

Сопоставление OBEPs с IBGWs

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение добавляет опцию I2CP для исходящих туннелей, которая заставляет туннели быть выбраны или построены таким образом, чтобы OBEP соответствовал одному из IBGWs из LeaseSet для целевой Destination.

Мотивация

Большинство маршрутизаторов I2P используют форму отбрасывания пакетов для управления перегрузками. Реализация по умолчанию использует стратегию WRED, учитывающую как размер сообщения, так и расстояние передачи (см. документацию tunnel throttling ). Из-за этой стратегии основным источником потери пакетов является OBEP.

Дизайн

При отправке сообщения отправитель выбирает или строит туннель с OBEP, который является тем же маршрутизатором, что и один из IBGWs получателя. Таким образом, сообщение будет выходить прямо из одного туннеля и попадать в другой, без необходимости пересылки через сеть между ними.

Сохранение ключей LeaseSet

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение касается сохранения дополнительной информации в LeaseSet, которая в настоящее время является эфемерной. Реализовано в 0.9.18.

Мотивация

В 0.9.17 была добавлена возможность сохранения ключа сегментации netDb, хранящегося в i2ptunnel.config. Это помогает предотвратить некоторые атаки, сохраняя тот же сегмент после перезапуска, и также предотвращает возможную корреляцию с перезапуском роутера.

Есть две другие вещи, которые еще легче сопоставить с перезапуском роутера: ключи шифрования и подписи LeaseSet. В настоящее время они не сохраняются.

Список блокировки в формате SU3

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение направлено на распространение обновлений списка блокировки в отдельном файле su3.

Мотивация

Без этого списка блокировки обновляются только в релизе. Этот формат может использоваться в различных реализациях маршрутизаторов.

Концепция

Определите формат, чтобы он был обернут в файл su3. Разрешите блокировку по IP или хэшу маршрутизатора. Маршрутизаторы могут подписаться на URL или импортировать файл, полученный другими способами. Файл su3 содержит подпись, которую необходимо проверить при импорте.

Спецификация

Будет добавлено на страницу спецификации обновления маршрутизатора.

Срок истечения интродюсера

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

В данном предложении речь идет об улучшении доли успешных подключений при установлении соединений.

Мотивация

Интрогерсеры (introducers) перестают действовать по истечении определённого времени, однако эта информация не публикуется в Router Info. В настоящее время маршрутизаторам приходится использовать эвристику для оценки, когда интрогерсер уже недействителен.

Дизайн

В SSU-адресе маршрутизатора, содержащем интрогерсеров, публикующий может опционально указать время истечения срока действия для каждого интрогерсера.

Спецификация

iexp{X}={nnnnnnnnnn}

X :: Номер интрогерсера (0-2)

nnnnnnnnnn :: Время в секундах (не миллисекундах) с эпохи Unix.

Примечания

Каждое время истечения должно быть больше даты публикации Router Info и меньше, чем на 6 часов превышать дату публикации Router Info.

Стриминговый MTU для пунктов назначения ECIES

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Сетевое развертывание и тестирование в процессе. Возможны незначительные правки.

Обзор

Краткое содержание

ECIES уменьшает накладные расходы существующего сеансового (ES) сообщения примерно на 90 байт. Следовательно, мы можем увеличить MTU примерно на 90 байт для соединений ECIES. См. спецификацию ECIES , спецификацию Streaming и документацию по API Streaming .

Без увеличения MTU в большинстве случаев экономия на накладных расходах фактически не «сохраняется», так как сообщения всё равно будут дополняться до двух полных туннельных сообщений.

Схема подписи Red25519

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Развертывание и тестирование сети в процессе. Возможны незначительные изменения. См. specification для официальной спецификации.

Обзор

Это предложение описывает повторно рандомизируемую схему подписи, подходящую для создания Назначений, которые могут быть ослеплены. Кроме того, она может быть использована для ослепления существующих Ed25519 Назначений, с незначительным снижением эффективности.

Мотивация

Proposal 123 определяет зашифрованный формат LeaseSet2, который воплощает принцип наименьших полномочий: каждому участнику сети предоставляется только та информация, которая необходима для его роли. В частности, зашифрованный LeaseSet2, опубликованный в floodfill, не раскрывает назначение, для которого он предназначен, и Лизы могут быть просмотрены только теми, кто уже знает о Назначении. Однако floodfills все еще должны иметь возможность аутентифицировать зашифрованные LeaseSet2 при их публикации, и клиенты должны дополнительно убедиться, что аутентификация была выполнена самим Назначением.

Тестирование IPv6 Peer

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Предложение заключается во внедрении тестирования SSU Peer для IPv6. Реализовано в 0.9.27.

Мотивация

Мы не можем надежно определить и отслеживать, находится ли наш IPv6-адрес за файрволом.

Когда несколько лет назад мы добавили поддержку IPv6, мы предполагали, что IPv6 никогда не блокируется файрволом.

Совсем недавно, в версии 0.9.20 (май 2015), мы разделили внутренний статус доступности v4/v6 (билет №1458). Подробную информацию и ссылки можно найти в этом билете.

Если у вас оба — v4 и v6 — находятся за файрволом, вы можете просто принудительно настроить файрвол в разделе конфигурации TCP на /confignet.

Тип подписи ГОСТ

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Подпись на эллиптической кривой ГОСТ Р 34.10 используется официальными лицами и предприятиями в России. Поддержка этого может упростить интеграцию существующих приложений (обычно на базе CryptoPro). Функция хеширования - ГОСТ Р 34.11 размером 32 или 64 байта. По сути, работает так же, как EcDSA, размер подписи и открытого ключа составляет 64 или 128 байт.

Мотивация

Криптография на эллиптических кривых никогда не вызывала полное доверие и порождала множество спекуляций относительно возможных закладок. Таким образом, нет универсального типа подписи, которому доверяют все. Добавление еще одного типа подписи даст людям больше выбора, чему они доверяют больше.

Типы MIME I2P

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Определите типы MIME для общих форматов файлов I2P. Включите определения в пакеты Debian. Предоставьте обработчик для типа .su3 и, возможно, других.

Мотивация

Чтобы упростить повторное содержание и установку плагинов при загрузке через браузер, нам нужен тип MIME и обработчик для файлов .su3.

Тем более, изучив, как писать файл определения MIME, следуя стандарту freedesktop.org, мы можем добавить определения для других общих типов файлов I2P. Хотя это менее полезно для файлов, которые обычно не загружаются, таких как база данных адресной книги (hostsdb.blockfile), эти определения позволят файлам быть лучше идентифицированными и снабженными иконками при использовании графического просмотрщика каталогов, такого как “nautilus” на Ubuntu.

Увеличение MTU IPv6

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение предполагает увеличение максимального MTU SSU IPv6 с 1472 до 1488. Реализовано в 0.9.28.

Мотивация

MTU IPv4 должен быть кратен 16 плюс 12. MTU IPv6 должен быть кратен 16.

Когда несколько лет назад была впервые добавлена поддержка IPv6, мы установили максимальный MTU IPv6 на 1472, что меньше MTU IPv4, равного 1484. Это было сделано для упрощения и гарантии, что MTU IPv6 будет меньше существующего MTU IPv4. Теперь, когда поддержка IPv6 стабильна, мы можем установить MTU IPv6 выше, чем MTU IPv4.

Улучшения IPv6 транспортировки

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

Сетевое развертывание и тестирование в процессе. Возможны незначительные правки.

Обзор

В данном предложении описывается реализация улучшений транспортов SSU и NTCP2 для IPv6.

Мотивация

По мере роста использования IPv6 по всему миру и увеличения числа конфигураций только с IPv6 (особенно на мобильных устройствах), нам необходимо улучшить поддержку IPv6 и устранить предположения о том, что все маршрутизаторы поддерживают IPv4.

Проверка соединения

При выборе пиров для туннелей или выборе путей OBEP/IBGW для маршрутизации сообщений полезно определить, может ли маршрутизатор A подключиться к маршрутизатору B. В общем случае это означает определение, имеет ли A исходящую возможность для транспорта и типа адреса (IPv4/v6), которая соответствует одному из входящих адресов B.

Устаревание имен хостов в адресах маршрутизатора

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Начиная с выпуска 0.9.32, обновите спецификацию netdb, чтобы устареть имена хостов в информации о маршрутизаторах, точнее, в отдельных адресах маршрутизаторов. Во всех реализациях I2P маршрутизаторы, настроенные с использованием имен хостов, должны заменять имена хостов на IP-адреса перед публикацией, и другие маршрутизаторы должны игнорировать адреса с именами хостов. Маршрутизаторы не должны выполнять DNS-запросы опубликованных имен хостов.

Мотивация

Имена хостов разрешены в адресах маршрутизаторов с самого начала I2P. Однако очень немногие маршрутизаторы публикуют имена хостов, так как это требует как публичного имени хоста (которое мало кто имеет), так и ручной настройки (которую мало кто делает). В недавней выборке 0,7% маршрутизаторов публиковали имя хоста.

Флаг I2CP для переключения исходящих туннелей

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Соединения потокового клиента могут зависать, когда подтверждения доставки теряются без уведомления. Отправитель повторно передаёт данные, пока не получит подтверждение или соединение не будет разорвано, при этом нет надёжного способа проверить, достигают ли подтверждения другой стороны. В данном предложении добавляется один новый флаговый бит в поле флагов SendMessageExpiresMessage , чтобы клиент мог указать маршрутизатору выбрать другой исходящий тоннель для последующих сообщений тому же получателю. Протокол потоковой передачи использует этот бит для инициации смены тоннеля при обнаружении зависшего соединения.

Шифрование туннельного уровня через ChaCha

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Это предложение основывается на изменениях из предложения 152: Туннели ECIES.

Только туннели, построенные через узлы, поддерживающие форматы BuildRequestRecord для туннелей ECIES-X25519, могут реализовать эту спецификацию.

Эта спецификация требует использования формата Tunnel Build Options для указания типа шифрования уровня туннеля и передачи ключей для уровня AEAD.

Цели

Целями данного предложения являются:

Замена AES256/ECB+CBC на ChaCha20 для установленного шифрования туннельного IV и уровня
Использование ChaCha20-Poly1305 для AEAD-защиты между узлами
Быть неотличимым от существующего шифрования уровня туннеля для участников, не использующих туннель
Не изменять общую длину туннельного сообщения

Обработка установленного туннельного сообщения

Этот раздел описывает изменения для: