Обзор
ElGamal/AES+SessionTags используется для сквозного шифрования.
Будучи ненадежной, неупорядоченной, основанной на сообщениях системой, I2P использует простую комбинацию асимметричных и симметричных алгоритмов шифрования для обеспечения конфиденциальности и целостности чесночных сообщений. В целом, эта комбинация известна как ElGamal/AES+SessionTags, но это чрезмерно многословный способ описания использования 2048-битного ElGamal, AES256, SHA256 и 32-байтных однократно используемых чисел (nonce).
Когда маршрутизатор впервые хочет зашифровать чесночное сообщение для другого маршрутизатора, он шифрует ключевой материал для сеансового ключа AES256 с помощью ElGamal и добавляет зашифрованную полезную нагрузку AES256/CBC после этого зашифрованного блока ElGamal. Помимо зашифрованной полезной нагрузки, зашифрованная секция AES содержит длину полезной нагрузки, хеш SHA256 незашифрованной полезной нагрузки, а также ряд "метки сессии" - случайные 32-байтовые однократно используемые числа (nonce). В следующий раз, когда отправитель захочет зашифровать чесночное сообщение для другого маршрутизатора, вместо того, чтобы ElGamal зашифровал новый сеансовый ключ, они просто выбирают одну из ранее переданных сеансовых меток и AES шифруют полезную нагрузку, как и раньше, используя ключ сеанса, использованный с этим тегом сеанса. Когда маршрутизатор получает чесночное зашифрованное сообщение, он проверяет первые 32 байта на соответствие доступному сеансовому тегу: если да, то они просто расшифровывают сообщение с помощью AES, а если нет, то они расшифровывают первый блок методом ElGamal.
Каждая метка сеанса может быть использована только один раз, чтобы предотвратить ненужное соотношение различных сообщений между одними и теми же маршрутизаторами. Отправитель зашифрованного сообщения ElGamal/AES+SessionTag выбирает когда и сколько меток доставить, предварительно снабдив получателя достаточным количеством меток чтобы покрыть залп сообщений. Чесночные сообщения могут выявить успешную доставку метки путем упаковки небольшого дополнительного сообщения в виде зубчика ("сообщение о статусе доставки "): когда чесночное сообщение доставляется адресату и успешно расшифровывается, это небольшое сообщение о статусе доставки является одним из распаковывающихся зубчиков и содержит инструкции для получателя по отправке зубчика обратно отправителю (разумеется, через входящий туннель). Когда отправитель получает это сообщение о статусе доставки, он знает, что теги сессии включенные в чесночное сообщение, были успешно доставлены.
Сами метки сеанса имеют короткий срок службы, после чего они выбрасываются, если не используются. Кроме того, количество хранимых ключей ограничено, как и количество самих ключей: если их поступает слишком много, новые или старые сообщения могут быть потеряны. Отправитель отслеживает, проходят ли сообщения с использованием сеансовых тегов. и если связи недостаточно, он может отбросить те сообщения, которые ранее считались доставленными должным образом, таким образом вернувшись обратно к полному шифрованию ElGamal. Сессия будет продолжаться до тех пор, пока все ее метки не будут исчерпаны или не истекут.
Сессии являются однонаправленными. Метки передаются от Алисы Бобу, а Алиса затем использует эти метки, одну за другой, в последующих сообщениях Бобу.
Сеансы могут быть установлены между адресами назначения, между маршрутизаторами или между маршрутизатором и адресом назначения. Каждый маршрутизатор и адрес назначения поддерживает собственный менеджер сеансовых ключей для того, чтобы отследить сеансовые ключи и сеансовые метки. Отдельные менеджеры сеансовых ключей предотвращают корреляцию противниками нескольких адресов назначения друг с другом или маршрутизатором.
Прием сообщений
Каждое полученное сообщение имеет одно из двух двух возможных условий:
- Он является частью существующей сессии и содержит тег сессии и зашифрованный блок AES.
- Он предназначен для новой сессии и содержит зашифрованные блоки ElGamal и AES.
Когда маршрутизатор получает сообщение, он сначала предположит, что это сообщение от существующей сессии и попытается найти тег сессии и расшифровать следующие данные с помощью AES. Если это не удастся, он предположит, что это сообщение для новой сессии, и попытается расшифровать его с помощью ElGamal.
Спецификация нового сеансового сообщения
Сообщение ElGamal новой сессии содержит две части - зашифрованный блок ElGamal и зашифрованный блок AES.
Зашифрованное сообщение содержит:
+----+----+----+----+----+----+----+----+
| |
+ +
| ElGamal Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| | |
+----+----+ +
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
Блок Эль-Гамаля
Зашифрованный блок Эль-Гамаля всегда длиной 514 байт.
Незашифрованные данные ElGamal имеют длину 222 байта и содержат:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Key |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| Pre-IV |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
+ +
| |
+ +
| 158 bytes random padding |
~ ~
| |
+ +----+----+
| |
+----+----+----+----+----+----+
32 байта Session Key является идентификатором сессии. 32-байтовый Pre-IV будет использоваn для генерации IV для следующего блока AES; IV - это первые 16 байтa хеша SHA-256 Pre-IV.
Полезная нагрузка размером 222 байта шифруется с помощью ElGamal а длина зашифрованного блока составляет 514 байтов.
Блок AES
Незашифрованные данные в блоке AES содержат следующее:
+----+----+----+----+----+----+----+----+
|tag count| |
+----+----+ +
| |
+ +
| Session Tags |
~ ~
| |
+ +
| |
+ +----+----+----+----+----+----+
| | payload size | |
+----+----+----+----+----+----+ +
| |
+ +
| Payload Hash |
+ +
| |
+ +----+----+
| |flag| |
+----+----+----+----+----+----+----+ +
| |
+ +
| New Session Key (opt.) |
+ +
| |
+ +----+
| | |
+----+----+----+----+----+----+----+ +
| |
+ +
| Payload |
~ ~
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
Definition
tag count:
2-byte Integer, 0-200
Session Tags:
That many 32-byte SessionTags
payload size:
4-byte Integer
Payload Hash:
The 32-byte SHA256 Hash of the payload
flag:
A one-byte value. Normally == 0. If == 0x01, a Session Key follows
New Session Key:
A 32-byte SessionKey,
to replace the old key, and is only present if preceding flag is 0x01
Payload: the data
Padding:
Random data to a multiple of 16 bytes for the total length.
May contain more than the minimum required padding.
Затем данные шифруются AES, используя сеансовый ключ и IV (вычисленный из предварительного IV) из раздела ElGamal. Длина зашифрованного блока AES переменна, но всегда кратна 16 байтам.
Примечания
- Фактическая максимальная длина полезной нагрузки и максимальная длина блока составляет менее 64 КБ; см. обзор I2NP.
- Новый сеансовый ключ в настоящее время не используется и никогда не присутствует.
Спецификация сообщений о существующем сеансе
Успешно доставленные метки сеанса запоминаются на короткий период времени (в настоящее время 15 минут), пока они не будут использованы или сброшены. Метка используется путем её упаковки в существующее сообщение сессии, которое содержит только зашифрованный блок AES, и ему не предшествует блок ElGamal.
Существующее сообщение о сеансе:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Tag |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Definition
Session Tag:
A 32-byte SessionTag
previously delivered in an AES block
AES Encrypyted Block: As specified above.
Сеансовая метка также служит в качестве предварительного IV. IV - это первые 16 байт хэша SHA-256 тега сессии.
Чтобы декодировать сообщение из существующей сессии, маршрутизатор просматривает тег сессии, чтобы найти связанный с ним ключ сеанса. Если тег сессии найден, блок AES расшифровывается с помощью связанного ключа сессии. Если тег не найден, сообщение считается Сообщением новой сессии .
Опции конфигурации меток сессии
Начиная с версии 0.9.2, клиент может настроить количество отправляемых по умолчанию сеансовых тегов и нижний порог тегов для текущего сеанса. Для коротких потоковых соединений или дейтаграмм эти параметры могут быть использованы для значительного снижения пропускной способности. Подробнее см. в спецификации опций I2CP. Параметры сеанса также могут быть отменены на уровне отдельного сообщения. Подробнее см. в спецификации сообщения истечения срока I2CP.
Предстоящая работа
Note: ElGamal/AES+SessionTags is being replaced with ECIES-X25519-AEAD-Ratchet (Proposal 144). The issues and ideas referenced below have been incorporated into the design of the new protocol. The following items will not be addressed in ElGamal/AES+SessionTags.
Существует множество возможных областей для настройки алгоритмов менеджера сеансовых ключей; некоторые из них могут взаимодействовать с поведением потоковой библиотеки или оказывать значительное влияние на общую производительность.
- Количество передаваемых тегов может зависеть от размера сообщения, учитывая возможное сокращение до 1 КБ на уровне туннельных сообщений.
- Клиенты могли бы отправлять маршрутизатору оценку времени жизни сеанса в качестве рекомендации о необходимом количестве меток.
- Доставка слишком малого количества меток заставляет маршрутизатор вернуться к дорогостоящему шифрованию ElGamal.
- Маршрутизатор может предполагать доставку сеансовых меток или ожидать подтверждения перед их использованием; для каждой стратегии есть свои компромиссы.
- Для очень коротких сообщений почти все 222 байта полей pre-IV и изменение размеров в блоке ElGamal могут быть использованы для всего сообщения вместо установления сеанса.
- Оценить стратегию изменения размера; в настоящее время мы заполняем минимум 128 байтов. Было бы лучше добавить несколько тегов к маленьким сообщениям, чем набивать их.
- Возможно, система сеансовых меток была бы более эффективной, если бы она была двунаправленной, чтобы теги, переданные по "прямому" пути, могли быть использованы в "обратном" пути, таким образом избегая ElGamal в первоначальном ответе. В настоящее время маршрутизатор использует некоторые подобные трюки при отправке туннельных тестовых сообщений самому себе.
- Переход от сеансовых меток к синхронизированный ГПСЧ.
- Некоторые из этих идей могут потребовать нового типа сообщения I2NP, или установить флаг в Инструкции по доставке , или установить магическое число в первых нескольких байтах поля Session Key и принять небольшой риск того, что случайный ключ сеанса совпадет с магическим числом.