Примечание
Реализовано в версии 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.
Меньшие сообщения позволили бы сэкономить пропускную способность. Также, если сообщения можно было бы вписать в одно туннельное сообщение, обратный путь стал бы в три раза более эффективным.
Это предложение определяет новые записи запросов и ответов и новые сообщения Build Request и Build Reply.
Создатель туннеля и все узлы в созданном туннеле должны быть ECIES-X25519, и по крайней мере версии 0.9.51. Это предложение не станет полезным, пока большинство маршрутизаторов в сети не будут ECIES-X25519. Это ожидается к концу 2021 года.
Цели
См. Prop152 и Prop156 для дополнительных целей.
- Меньшие записи и сообщения
- Поддержание достаточного места для будущих опций, как в Prop152 и Tunnel-Creation-ECIES
- Вписывание в одно туннельное сообщение для обратного пути
- Поддержка только узлов ECIES
- Поддержание улучшений, реализованных в Prop152 и Tunnel-Creation-ECIES
- Максимальная совместимость с текущей сетью
- Скрытие входящих сообщений построения от OBEP
- Скрытие исходящих сообщений ответа построения от IBGW
- Не требовать полного обновления всей сети (“flag day”)
- Плавное развертывание для минимизации рисков
- Повторное использование существующих криптографических примитивов
Не-Цели
См. Prop156 для дополнительных не-целей.
- Отсутствие требования для смешанных туннелей ElGamal/ECIES
- Изменения шифрования слоя, для этого см. Prop153
- Отсутствие ускорений криптоопераций. Предполагается, что ChaCha20 и AES схожи, даже при использовании AESNI, по крайней мере для рассматриваемых мелких объемов данных.
Дизайн
Записи
См. приложение для расчетов.
Зашифрованные записи запроса и ответа будут занимать 218 байт, по сравнению с 528 байтами сейчас.
Записи нешифрованного запроса будут занимать 154 байта, по сравнению с записями ElGamal, которые занимают 222 байта, и записями ECIES, определенными в Prop152 и Tunnel-Creation-ECIES, которые занимают 464 байта.
Записи нешифрованного ответа будут занимать 202 байта, по сравнению с записями ElGamal, которые занимают 496 байт, и записями ECIES, определенными в Prop152 и Tunnel-Creation-ECIES, которые занимают 512 байт.
Шифрование ответа будет ChaCha20 (НЕ ChaCha20/Poly1305), поэтому нешифрованные записи не нуждаются в кратности 16 байтам.
Записи запроса будут сделаны меньше с использованием HKDF для создания ключей и ключей ответа слоя, так что их не нужно будет явно включать в запрос.
Сообщения Построения Туннеля
Оба сообщения будут “переменными” с однобайтовым полем количества записей, как в существующих переменных сообщениях.
ShortTunnelBuild: Тип 25
Типичная длина (с 4 записями): 873 байта
При использовании для построения входящих туннелей рекомендуется (но не требуется), чтобы это сообщение было зашифровано garlic шифрованием отправителем, нацеливаясь на входной шлюз (инструкции доставки ROUTER), чтобы скрыть входящие сообщения построения от OBEP. IBGW расшифровывает сообщение, помещает ответ в правильный слот, и отправляет ShortTunnelBuildMessage следующему шагу.
Длина записи выбрана так, чтобы зашифрованный garlic STBM мог вписаться в одно туннельное сообщение. См. приложение ниже.
OutboundTunnelBuildReply: Тип 26
Мы определяем новое сообщение OutboundTunnelBuildReply. Оно используется только для построения исходящих туннелей. Цель состоит в том, чтобы скрыть исходящие сообщения ответа на построение от IBGW. Оно должно быть зашифровано garlic шифрованием OBEP, нацеленным на отправителя (инструкции доставки TUNNEL). OBEP расшифровывает сообщение построения туннеля, конструирует сообщение OutboundTunnelBuildReply, и помещает ответ в поле открытого текста. Остальные записи размещаются в других слотах. Затем оно зашифровывает сообщение для отправителя с использованием производных симметричных ключей.
Примечания
Шифруя garlic шифрованием OTBRM и STBM, мы также избегаем любых потенциальных проблем с совместимостью у IBGW и OBEP спаренных туннелей.
Поток Сообщений
STBM: Короткое сообщение построения туннеля (тип 25)
OTBRM: Сообщение ответа на построение исходящего туннеля (тип 26)
Исходящее Построение A-B-C
Ответ через существующий входящий D-E-F
Новый Туннель
STBM STBM STBM
Создатель ------> A ------> B ------> C ---\
OBEP \
| Зашифровано garlic шифрованием
| OTBRM
| (доставка TUNNEL)
| от OBEP до
| создателя
Существующий Туннель /
Создатель <-------F---------E-------- D <--/
IBGW
Входящее Построение D-E-F
Отправлено через существующий исходящий A-B-C
Существующий Туннель
Создатель ------> A ------> B ------> C ---\
OBEP \
| Зашифровано garlic шифрованием (опционально)
| STBM
| (доставка ROUTER)
| от создателя
Новый Туннель | к IBGW
STBM STBM STBM /
Создатель <------ F <------ E <------ D <--/
IBGW
Шифрование Записей
Шифрование записей запроса и ответа: как определено в Prop152 и Tunnel-Creation-ECIES.
Шифрование записей ответа для других слотов: ChaCha20.
Шифрование Слоя
В настоящее время нет планов по изменению шифрования слоя для туннелей, построенных с использованием этой спецификации; оно останется AES, как и используется для всех туннелей.
Изменение шифрования слоя на ChaCha20 является темой для дополнительных исследований.
Новое Сообщение Данных Туннеля
В настоящее время нет планов по изменению 1KB Tunnel Data Message, используемого для туннелей, построенных с этой спецификацией.
Может быть полезно ввести новое сообщение I2NP, которое будет больше или переменной длины, одновременно с этим предложением, для использования через эти туннели. Это бы сократило оверхед для больших сообщений. Это является темой для дополнительных исследований.
Спецификация
Короткая Запись Запроса
Короткая Нешифрованная Запись Запроса
Это предлагаемая спецификация записи BuildRequestRecord для маршрутизаторов ECIES-X25519. Обзор изменений из Tunnel-Creation-ECIES:
- Изменение нешифрованной длины с 464 до 154 байт
- Изменение зашифрованной длины с 528 до 218 байт
- Удаление ключей и IV слоя и ответа, они будут сгенерированы из split() и KDF
Запись запроса не содержит ключей ответа ChaCha. Эти ключи генерируются из KDF. См. ниже.
Все поля в формате big-endian.
Нешифрованный размер: 154 байта.
байты 0-3: идентификатор туннеля для получения сообщений, ненулевой
байты 4-7: следующий идентификатор туннеля, ненулевой
байты 8-39: хеш идентификатора следующего маршрутизатора
байт 40: флаги
байты 41-42: дополнительные флаги, не используются, установлены в 0 для совместимости
байт 43: тип шифрования слоя
байты 44-47: время запроса (в минутах с момента эпохи, округлено вниз)
байты 48-51: срок действия запроса (в секундах с момента создания)
байты 52-55: следующий идентификатор сообщения
байты 56-x: параметры построения туннеля (Mapping)
байты x-x: другие данные как подразумевается флагами или параметрами
байты x-153: случайная вставка (см. ниже)
Поле флагов такое же как определено в Tunnel-Creation и содержит следующее:
Порядок битов: 76543210 (бит 7 - старший) бит 7: если установлен, разрешить сообщения от любого бит 6: если установлен, разрешить сообщения к любому, и отправить ответ на указанную следующую точку в сообщении Tunnel Build Reply биты 5-0: Не определено, должны быть установлены в 0 для совместимости с будущими опциями
Бит 7 указывает, что шаg будет входным шлюзом (IBGW). Бит 6 указывает, что шаг будет выходной конечной точкой (OBEP). Если ни один бит не установлен, то шаг будет промежуточным участником. Оба не могут быть установлены одновременно.
Тип шифрования слоя: 0 для AES (как в текущих туннелях); 1 для будущего (ChaCha?)
Срок действия запроса предназначен для будущей переменной продолжительности туннеля. На данный момент единственное поддерживаемое значение - 600 (10 минут).
Временный открытый ключ создателя является ключом ECIES, big-endian. Он используется для генерации KDF ключей и IV слоя и ответа IBGW. Этот ключ включается в открытой записи только в сообщении построения входящего туннеля. Он необходим, поскольку на этом этапе для записи построения нет DH.
Параметры построения туннеля - это структура Mapping, как определено в Common. Это для будущего использования. На данный момент не определено никаких параметров. Если структура Mapping пуста, это два байта 0x00 0x00. Максимальный размер Mapping (включая поле длины) - 98 байт, а максимальное значение поля длины Mapping - 96.
Короткая Зашифрованная Запись Запроса
Все поля в формате big-endian, за исключением временного открытого ключа, который в формате little-endian.
Зашифрованный размер: 218 байт
байты 0-15: усеченный хеш идентификатора перехода
байты 16-47: временный публичный X25519 ключ отправителя
байты 48-201: ChaCha20 зашифрованный ShortBuildRequestRecord
байты 202-217: Poly1305 MAC
Короткая Запись Ответа
Короткая Нешифрованная Запись Ответа
Это предлагаемая спецификация записи ShortBuildReplyRecord для маршрутизаторов ECIES-X25519. Обзор изменений из Tunnel-Creation-ECIES:
- Изменение нешифрованной длины с 512 до 202 байт
- Изменение зашифрованной длины с 528 до 218 байт
Ответы ECIES зашифрованы с использованием ChaCha20/Poly1305.
Все поля в формате big-endian.
Нешифрованный размер: 202 байта.
байты 0-x: Параметры Ответа на Построение Туннеля (Mapping)
байты x-x: другие данные как подразумевается параметрами
байты x-200: Случайная вставка (см. ниже)
байт 201: Байт ответа
Параметры ответа на построение туннеля - это структура Mapping, как определено в Common. Это для будущего использования. На данный момент не определено никаких параметров. Если структура Mapping пуста, это два байта 0x00 0x00. Максимальный размер Mapping (включая поле длины) - 201 байт, а максимальное значение поля длины Mapping - 199.
Байт ответа является одним из следующих значений как определено в Tunnel-Creation для предотвращения фингерпринтинга:
- 0x00 (принять)
- 30 (TUNNEL_REJECT_BANDWIDTH)
Короткая Зашифрованная Запись Ответа
Зашифрованный размер: 218 байт
байты 0-201: ChaCha20 зашифрованная ShortBuildReplyRecord
байты 202-217: Poly1305 MAC
KDF
См. раздел KDF ниже.
ShortTunnelBuild
I2NP Тип 25
Это сообщение отправляется средним переходам, OBEP и IBEP (создатель). Оно не может быть отправлено на IBGW (используйте garlic обернутое InboundTunnelBuild вместо этого). Когда оно получено OBEP, оно преобразуется в OutboundTunnelBuildReply, обернуто в garlic, и отправляется отправителю.
+----+----+----+----+----+----+----+----+
| num| ShortBuildRequestRecords...
+----+----+----+----+----+----+----+----+
num ::
1 байт `Integer`
Допустимые значения: 1-8
размер записи: 218 байт
общий размер: 1+$num*218
Примечания
- Типичное количество записей - 4, для общего размера в 873 байта.
OutboundTunnelBuildReply
I2NP Тип 26
Это сообщение отправляется только OBEP к IBEP (создателю) через существующий входящий туннель. Оно не может быть отправлено на любой другой узел. Оно всегда обернуто в garlic шифрование.
+----+----+----+----+----+----+----+----+
| num| |
+----+ +
| ShortBuildReplyRecords... |
+----+----+----+----+----+----+----+----+
num ::
Общее количество записей,
1 байт `Integer`
Допустимые значения: 1-8
ShortBuildReplyRecords ::
Зашифрованные записи
длина: num * 218
размер зашифрованной записи: 218 байт
общий размер: 1+$num*218
Примечания
- Типичное количество записей - 4, для общего размера в 873 байта.
- Это сообщение должно быть зашифровано garlic.
KDF
Мы используем ck из состояния Noise после шифрования/расшифровки записи построения туннеля для вывода следующих ключей: ключ ответа, ключ шифрования слоя AES, ключ IV AES и ключ/тег garlic ответа для OBEP.
Ключ ответа: В отличие от длинных записей, мы не можем использовать левую часть ck для ключа ответа, так как он не последний и будет использован позже. Ключ ответа используется для шифрования ответа этой записи с использованием AEAD/Chaha20/Poly1305 и Chacha20 для ответа другим записям. Обе используют один и тот же ключ, nonce - это позиция записи в сообщении, начиная с 0.
keydata = HKDF(ck, ZEROLEN, "SMTunnelReplyKey", 64)
replyKey = keydata[32:63]
ck = keydata[0:31]
Ключ слоя:
Ключ слоя всегда AES на данный момент, но то же KDF можно использовать для Chacha20
keydata = HKDF(ck, ZEROLEN, "SMTunnelLayerKey", 64)
layerKey = keydata[32:63]
Ключ IV для не-OBEP записи:
ivKey = keydata[0:31]
потому что он последний
Ключ IV для записи OBEP:
ck = keydata[0:31]
keydata = HKDF(ck, ZEROLEN, "TunnelLayerIVKey", 64)
ivKey = keydata[32:63]
ck = keydata[0:31]
OBEP garlic ключ ответа/тег:
keydata = HKDF(ck, ZEROLEN, "RGarlicKeyAndTag", 64)
replyKey = keydata[32:63]
replyTag = keydata[0:7]
Обоснование
Данный дизайн максимально использует повторное использование существующих криптографических примитивов, протоколов и кода.
Этот дизайн минимизирует риски.
ChaCha20 слегка быстрее AES для мелких записей, согласно тестам на Java. ChaCha20 избегает требования к кратности размеров данных 16 байтам.
Примечания к Реализации
- Как и в существующем переменном сообщении построения туннеля, сообщения с количеством записей менее 4 нежелательны. Типичное значение по умолчанию - 3 узла. Входящие туннели должны быть построены с дополнительной записью для отправителя, чтобы последний этап не знал, что он последний. Чтобы средние этапы не знали, обсуждается ли туннель входящим или исходящим, исходящие туннели также должны быть построены с 4 записями.
Вопросы
Миграция
Реализация, тестирование и развертывание займут несколько выпусков и приблизительно один год. Этапы следующие. Назначение каждого этапа на конкретный выпуск TBD и зависит от темпа разработки.
Детали реализации и миграции могут варьироваться для каждой реализации I2P.
Создатель туннеля должен убедиться, что все переходы в созданном туннеле ECIES-X25519, И как минимум версии TBD. Создатель туннеля НЕ обязательно должен быть ECIES-X25519; он может быть ElGamal. Однако, если создатель ElGamal, это раскрывает ближайшему переходу, что он является создателем. Таким образом, на практике, эти туннели должны создаваться только маршрутизаторами ECIES.
Не должно быть необходимости, чтобы спаренный туннель OBEP или IBGW был ECIES или какой-либо конкретной версии. Новые сообщения зашифрованы garlic и не видимы на OBEP или IBGW спаренного туннеля.
Этап 1: Реализация, не включена по умолчанию
Этап 2 (следующий выпуск): Включение по умолчанию
Нет проблем с обратной совместимостью. Новые сообщения могут быть отправлены только маршрутизаторам, которые их поддерживают.
Приложение
Без оверхеда garlic для незашифрованного входящего STBM, если мы не используем ITBM:
Текущий размер для 4 слотов: 4 * 528 + оверхед = 3 туннельных сообщения
Сообщение построения для 4 слотов, чтобы вписаться в одно туннельное сообщение, только ECIES:
1024
- 21 заголовок фрагмента
----
1003
- 35 инструкции доставки необработанного ROUTER
----
968
- 16 заголовок I2NP
----
952
- 1 количество слотов
----
951
/ 4 слота
----
237 Новый размер зашифрованной записи построения (в сравнении с 528 в настоящее время)
- 16 укороченный хеш
- 32 временный ключ
- 16 MAC
----
173 максимальный размер открытого текста записи построения (в сравнении с 222 в настоящее время)
С учетом оверхеда garlic для ‘N’ паттерна noise для шифрования входящего STBM, если мы не используем ITBM:
Текущий размер для 4 слотов: 4 * 528 + оверхед = 3 туннельных сообщения
Зашифрованное garlic сообщение построения для 4 слотов, чтобы вписаться в одно туннельное сообщение, только ECIES:
1024
- 21 заголовок фрагмента
----
1003
- 35 инструкции доставки необработанного ROUTER
----
968
- 16 заголовок I2NP
- 4 длина
----
948
- 32 байта временного ключа
----
916
- 7 байт блок DateTime
----
909
- 3 байта оверхеда Garlic блока
----
906
- 9 байт заголовка I2NP
----
897
- 1 байт инструкции локальной доставки Garlic
----
896
- 16 байт Poly1305 MAC
----
880
- 1 количество слотов
----
879
/ 4 слота
----
219 Новый размер зашифрованной записи построения (в сравнении с 528 в настоящее время)
- 16 укороченный хеш
- 32 временный ключ
- 16 MAC
----
155 максимальный размер открытого текста записи построения (в сравнении с 222 в настоящее время)
Примечания:
Текущий размер открытого текста записи перед неиспользуемой вставкой: 193
Удаление полного хеша маршрутизатора и генерация HKDF ключей/IV освободит много места для будущих опций. Если все использует HKDF, требуется около 58 байт пространства открытого текста (без учета опций).
Garlic-обернутый OTBRM будет немного меньше, чем garlic-обернутый STBM, потому что инструкции доставки LOCAL, а не ROUTER, включён блок DATETIME, и используется 8-байтовый тег вместо 32-байтового временного ключа для полных сообщений ‘N’.