Статус
Одобрено на рассмотрении 2025-04-15. Изменения включены в спецификации. Реализовано в Java I2P, начиная с API 0.9.66. Проверьте документацию по реализации для получения информации о статусе.
Обзор
Выделено из Prop123 как отдельное предложение.
Оффлайн подписи не могут быть проверены в процессе обработки датаграмм с возможностью ответа. Необходимо флаг для указания на оффлайн подписанную дату, но нет места для размещения флага.
Потребуется полностью новый номер и формат протокола I2CP, который будет добавлен в спецификацию DATAGRAMS. Назовем его “Datagram2”.
Цели
- Добавить поддержку оффлайн подписей
- Добавить сопротивляемость к повторениям
- Добавить вариант без подписей
- Добавить поля флагов и опций для расширяемости
Не цели
Полная поддержка от конца до конца для управления перегрузкой и др. Это будет построено поверх или как альтернатива Datagram2, который является низкоуровневым протоколом. Было бы бессмысленно проектировать высокопроизводительный протокол исключительно на основе Datagram2 из-за поля from и накладных расходов на подписи. Любой такой протокол должен осуществить начальное рукопожатие с помощью Datagram2 и затем переключиться на RAW датаграммы.
Мотивация
Оставлено от работы над LS2, завершенной в 2019 году.
Первым приложением, использующим Datagram2, ожидается будет анонс битторрент UDP, как реализовано в i2psnark и zzzot, см. Prop160.
Спецификация Datagram с возможностью ответа
Для справки, ниже приведен обзор спецификации для датаграмм с возможностью ответа, скопированный из Datagrams. Стандартный номер протокола I2CP для датаграмм с возможностью ответа - PROTO_DATAGRAM (17).
+----+----+----+----+----+----+----+----+
| from |
+ +
| |
~ ~
~ ~
| |
+ +
| |
| |
+----+----+----+----+----+----+----+----+
| signature |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| payload...
+----+----+----+----//
from :: `Destination`
длина: 387+ байт
Происхождение и подписант датаграммы
signature :: `Signature`
Тип подписи должен соответствовать типу публичного ключа подписи $from
длина: 40+ байт, в зависимости от типа подписи.
Для стандартного типа ключа DSA_SHA1:
DSA `Signature` SHA-256 хеша полезной нагрузки.
Для других типов ключей:
`Signature` полезной нагрузки.
Подпись может быть проверена по публичному ключу подписи $from
payload :: Данные
Длина: от 0 до около 31,5 КБ (см. примечания)
Общая длина: Длина полезной нагрузки + 423+
Дизайн
- Определить новый протокол 19 - Датаграмма с возможностью ответа с опциями.
- Определить новый протокол 20 - Датаграмма с возможностью ответа без подписи.
- Добавить поле флагов для оффлайн подписей и будущего расширения.
- Переместить подпись после полезной нагрузки для более легкой обработки.
- Новая спецификация подписи, отличная от датаграмм с возможностью ответа или потоковых, чтобы проверка подписи не удалась, если ее интерпретировать как датаграмму с возможностью ответа или потоковую. Это достигается перемещением подписи после полезной нагрузки, и добавлением хеша назначения в функцию подписи.
- Добавить предотвращение повторов для датаграмм, как это было сделано в Prop164 для потоков.
- Добавить раздел для произвольных опций
- Повторно использовать формат оффлайн подписей из Common и Streaming.
- Раздел оффлайн подписи должен быть перед полями полезной нагрузки переменной длины и подписи, так как он определяет длину подписи.
Спецификация
Протокол
Новый номер протокола I2CP для Datagram2 - 19. Добавьте его как PROTO_DATAGRAM2 в I2CP.
Новый номер протокола I2CP для Datagram3 - 20. Добавьте его как PROTO_DATAGRAM2 в I2CP.
Формат Datagram2
Добавьте Datagram2 в DATAGRAMS следующим образом:
+----+----+----+----+----+----+----+----+
| |
~ from ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ offline_signature (optional) ~
~ expires, sigtype, pubkey, offsig ~
| |
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| |
~ signature ~
~ ~
| |
+----+----+----+----+----+----+----+----+
from :: `Destination`
длина: 387+ байт
Происхождение и (если не подпись оффлайн) подписант датаграммы
flags :: (2 байта)
Порядок битов: 15 14 ... 3 2 1 0
Биты 3-0: Версия: 0x02 (0 0 1 0)
Бит 4: Если 0, нет опций; если 1, карта опций включена
Бит 5: Если 0, нет оффлайн подписи; если 1, оффлайн подписано
Биты 15-6: не используется, установить в 0 для совместимости с будущими использованиями
options :: (2+ байта, если присутствуют)
Если флаг указывает, что опции присутствуют, `Mapping`
содержащий произвольные текстовые опции
offline_signature ::
Если флаг указывает на оффлайн ключи, секция оффлайн подписи,
как указано в Общих структурах спецификации,
с 4 следующими полями. Длина варьируется в зависимости от типов сигнатур онлайн и оффлайн,
обычно 102 байта для Ed25519
Эта секция может и должна быть сгенерирована оффлайн.
expires :: Время истечения
(4 байта, big endian, секунды с начала эпохи, переполняется в 2106)
sigtype :: Тип временной сигнатуры (2 байта, big endian)
pubkey :: Временный публичный ключ подписи (длина определяется типом сигнатуры),
обычно 32 байта для типа сигнатуры Ed25519.
offsig :: `Signature`
Подпись времени истечения, типа временной сигнатуры,
и публичного ключа, выполняемая публичным ключом назначения,
длина: 40+ байт, как подразумевается типом сигнатуры, обычно
64 байта для типа сигнатуры Ed25519.
payload :: Данные
Длина: от 0 до около 61 КБ (см. примечания)
signature :: `Signature`
Тип подписи должен соответствовать типу публичного ключа подписи $from
(если нет оффлайн подписи) или типу временной сигнатуры
(если подписано оффлайн)
длина: 40+ байт, как подразумевается типом сигнатуры, обычно
64 байта для типа сигнатуры Ed25519.
`Signature` полезной нагрузки и других полей, как указано ниже.
Подпись проверяется по публичному ключу подписи $from
(если нет оффлайн подписи) или временным публичным ключем
(если подписано оффлайн)
Общая длина: минимум 433 + длина полезной нагрузки; типичная длина для отправителей X25519 и без оффлайн подписей: 457 + длина полезной нагрузки. Обратите внимание, что сообщение обычно сжимается с помощью gzip на уровне I2CP, что приведет к значительной экономии, если from дестинация поддается сжатию.
Примечание: Формат оффлайн подписи такой же, как в спецификации Общих структур Common и Streaming.
Подписи
Подпись охватывает следующие поля.
- Прелюдия: 32-байтовый хеш целевого назначения (не включен в датаграмму)
- flags
- options (если присутствуют)
- offline_signature (если присутствуют)
- payload
В датаграмме с возможностью ответа для типа ключа DSA_SHA1, подпись била на SHA-256 хеше полезной нагрузки, а не на самой полезной нагрузке; здесь подпись всегда охватывает поля выше (НЕ хеш), независимо от типа ключа.
Проверка ToHash
Получатели должны верифицировать подпись (используя свой хеш назначения) и отбрасывать датаграмму в случае неудачи, для предотвращения повторов.
Формат Datagram3
Добавьте Datagram3 в DATAGRAMS следующим образом:
+----+----+----+----+----+----+----+----+
| |
~ fromhash ~
~ ~
| |
+----+----+----+----+----+----+----+----+
| flags | options (optional) |
+----+----+ +
~ ~
~ ~
+----+----+----+----+----+----+----+----+
| |
~ payload ~
~ ~
| |
+----+----+----+----+----+----+----+----+
fromhash :: `Hash`
длина: 32 байта
Происхождение датаграммы
flags :: (2 байта)
Порядок битов: 15 14 ... 3 2 1 0
Биты 3-0: Версия: 0x03 (0 0 1 1)
Бит 4: Если 0, нет опций; если 1, карта опций включена
Биты 15-5: не используется, установить в 0 для совместимости с будущими использованиями
options :: (2+ байта, если присутствуют)
Если флаг указывает, что опции присутствуют, `Mapping`
содержащий произвольные текстовые опции
payload :: Данные
Длина: от 0 до около 61 КБ (см. примечания)
Общая длина: минимум 34 + длина полезной нагрузки.
SAM
Добавьте STYLE=DATAGRAM2 и STYLE=DATAGRAM3 в спецификацию SAMv3. Обновите информацию о оффлайн подписях.
Накладные расходы
Этот дизайн добавляет 2 байта накладных расходов для датаграмм с возможностью ответа для флагов. Это приемлемо.
Анализ безопасности
Включение хеша цели в подпись должно быть эффективным для предотвращения атак повторов.
Формат Datagram3 не содержит подписей, поэтому отправителя нельзя проверить, и атаки повторов возможны. Любая требуемая валидация должна производиться на уровне приложения, или маршрутизатором на уровне механизма зашифрования.
Примечания
- Практическая длина ограничена нижележащими уровнями протоколов - спецификация туннельных сообщений TUNMSG ограничивает сообщения до около 61,2 КБ, и транспортные TRANSPORT в настоящее время ограничивают сообщения до около 64 КБ, так что длина данных здесь ограничена до около 61 КБ.
- См. важные заметки о надежности больших датаграмм API. Для наилучших результатов, ограничьте полезную нагрузку до около 10 КБ или меньше.
Совместимость
Отсутствует. Приложения необходимо переписать для маршрутизации сообщений I2CP Datagram2 на основе протокола и/или порта. Сообщения Datagram2, которые неправильно маршрутизируются и интерпретируются как Датаграммы с возможностью ответа или потоковые сообщения, потерпят неудачу на основе подписи, формата или обоих.
Миграция
Каждое приложение UDP должно отдельно обнаружить поддержку и мигрировать. Самое заметное приложение UDP это bittorrent.
Bittorrent
Bittorrent DHT: Вероятно, нужен флаг расширения, например, i2p_dg2, координируйте с BiglyBT
Bittorrent UDP Announces Prop160: Разработано изначально. Координируйте с BiglyBT, i2psnark, zzzot
Другие
Bote: Маловероятно, что будет мигрировать, не активно поддерживается
Streamr: Никто им не пользуется, миграция не планируется
SAM UDP приложения: Неизвестно