Обзор
ElGamal/AES+SessionTags используется для сквозного шифрования.
Как ненадёжная, неупорядоченная система на основе сообщений, I2P использует простую комбинацию асимметричных и симметричных алгоритмов шифрования для обеспечения конфиденциальности и целостности данных в garlic-сообщениях. В целом эта комбинация называется ElGamal/AES+SessionTags, но это излишне подробный способ описания использования 2048-битного ElGamal, AES256, SHA256 и 32-байтовых nonce.
В первый раз, когда router хочет зашифровать garlic-сообщение для другого router’а, он шифрует ключевой материал для сессионного ключа AES256 с помощью ElGamal и добавляет зашифрованную AES256/CBC полезную нагрузку после этого зашифрованного блока ElGamal. Помимо зашифрованной полезной нагрузки, раздел, зашифрованный AES, содержит длину полезной нагрузки, хеш SHA256 незашифрованной полезной нагрузки, а также несколько “session tags” - случайных 32-байтовых nonce. В следующий раз, когда отправитель хочет зашифровать garlic-сообщение для другого router’а, вместо ElGamal-шифрования нового сессионного ключа он просто выбирает один из ранее доставленных session tags и шифрует полезную нагрузку AES как прежде, используя сессионный ключ, который использовался с этим session tag, добавляя сам session tag в начало. Когда router получает зашифрованное garlic-сообщение, он проверяет первые 32 байта, чтобы увидеть, соответствуют ли они доступному session tag - если да, он просто расшифровывает сообщение AES, но если нет, он расшифровывает первый блок ElGamal.
Каждый тег сессии может быть использован только один раз, чтобы предотвратить ненужную корреляцию различных сообщений внутренними противниками как происходящих между одними и теми же router’ами. Отправитель сообщения, зашифрованного ElGamal/AES+SessionTag, выбирает когда и сколько тегов доставить, предварительно обеспечивая получателя достаточным количеством тегов для покрытия серии сообщений. Garlic сообщения могут обнаружить успешную доставку тега, включив небольшое дополнительное сообщение в качестве зубчика (“сообщение о статусе доставки”) - когда garlic сообщение прибывает к намеченному получателю и успешно расшифровывается, это небольшое сообщение о статусе доставки является одним из обнаруженных зубчиков и содержит инструкции для получателя отправить зубчик обратно первоначальному отправителю (через входящий tunnel, конечно). Когда первоначальный отправитель получает это сообщение о статусе доставки, он знает, что теги сессии, включенные в garlic сообщение, были успешно доставлены.
Сами session tags имеют короткое время жизни, после которого они отбрасываются, если не используются. Кроме того, количество тегов, хранящихся для каждого ключа, ограничено, как и количество самих ключей - если приходит слишком много, могут быть отброшены как новые, так и старые сообщения. Отправитель отслеживает, проходят ли сообщения, использующие session tags, и если связи недостаточно, он может отбросить те, которые ранее считались правильно доставленными, возвращаясь к полному дорогостоящему шифрованию ElGamal. Сессия будет продолжать существовать до тех пор, пока все её теги не будут исчерпаны или не истекут.
Сессии являются однонаправленными. Теги доставляются от Alice к Bob, и затем Alice использует теги, один за другим, в последующих сообщениях к Bob.
Сессии могут устанавливаться между Destinations, между роутерами или между роутером и Destination. Каждый роутер и Destination поддерживает собственный Session Key Manager для отслеживания Session Keys и Session Tags. Отдельные Session Key Managers предотвращают корреляцию нескольких Destinations друг с другом или с роутером со стороны противников.
Получение сообщений
Каждое полученное сообщение имеет одно из двух возможных состояний:
- Это часть существующей сессии и содержит Session Tag и AES зашифрованный блок
- Это для новой сессии и содержит как ElGamal, так и AES зашифрованные блоки
Когда router получает сообщение, он сначала предполагает, что оно от существующей сессии, и пытается найти Session Tag и расшифровать следующие данные с помощью AES. Если это не удается, он предполагает, что это для новой сессии, и пытается расшифровать его с помощью ElGamal.
Спецификация сообщения новой сессии
Сообщение ElGamal новой сессии содержит две части: зашифрованный блок ElGamal и зашифрованный блок AES.
Зашифрованное сообщение содержит:
+----+----+----+----+----+----+----+----+
| |
+ +
| ElGamal Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| | |
+----+----+ +
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
Блок ElGamal
Зашифрованный блок ElGamal всегда имеет длину 514 байт.
Незашифрованные данные ElGamal имеют длину 222 байта и содержат:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Key |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| Pre-IV |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
+ +
| |
+ +
| 158 bytes random padding |
~ ~
| |
+ +----+----+
| |
+----+----+----+----+----+----+
32-байтовый Session Key является идентификатором сессии. 32-байтовый Pre-IV будет использован для генерации IV для следующего блока AES; IV представляет собой первые 16 байт SHA-256 хеша от Pre-IV.
Полезная нагрузка размером 222 байта шифруется с использованием ElGamal , и зашифрованный блок имеет длину 514 байт.
AES Block
Незашифрованные данные в блоке AES содержат следующее:
+----+----+----+----+----+----+----+----+
|tag count| |
+----+----+ +
| |
+ +
| Session Tags |
~ ~
| |
+ +
| |
+ +----+----+----+----+----+----+
| | payload size | |
+----+----+----+----+----+----+ +
| |
+ +
| Payload Hash |
+ +
| |
+ +----+----+
| |flag| |
+----+----+----+----+----+----+----+ +
| |
+ +
| New Session Key (opt.) |
+ +
| |
+ +----+
| | |
+----+----+----+----+----+----+----+ +
| |
+ +
| Payload |
~ ~
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
Определение
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.
Минимальная длина: 48 байт
Затем данные шифруются AES , используя сессионный ключ и IV (вычисленный из предварительного IV) из секции ElGamal. Длина зашифрованного AES блока переменная, но всегда кратна 16 байтам.
Примечания
- Фактическая максимальная длина полезной нагрузки и максимальная длина блока составляет менее 64 КБ; см. Обзор I2NP .
- New Session Key в настоящее время не используется и никогда не присутствует.
Спецификация сообщения существующей сессии
Успешно доставленные теги сессии запоминаются на короткий период (в настоящее время 15 минут), пока они не будут использованы или отброшены. Тег используется путем упаковки его в сообщение существующей сессии, которое содержит только блок, зашифрованный AES, и не предшествует блоку ElGamal.
Существующее сообщение сессии выглядит следующим образом:
+----+----+----+----+----+----+----+----+
| |
+ +
| Session Tag |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Определение
Session Tag:
A 32-byte SessionTag
previously delivered in an AES block
AES Encrypted Block:
As specified above.
Тег сессии также служит в качестве pre-IV. IV представляет собой первые 16 байт SHA-256 хеша от sessionTag.
Для декодирования сообщения из существующей сессии router ищет Session Tag, чтобы найти связанный Session Key. Если Session Tag найден, блок AES расшифровывается с использованием связанного Session Key. Если тег не найден, предполагается, что сообщение является сообщением новой сессии .
Опции конфигурации тегов сессий
Начиная с версии 0.9.2, клиент может настроить количество Session Tags по умолчанию для отправки и низкий порог тегов для текущей сессии. Для коротких потоковых соединений или датаграмм эти опции могут использоваться для значительного сокращения пропускной способности. См. спецификацию опций I2CP для подробностей. Настройки сессии также могут быть переопределены для каждого сообщения отдельно. См. спецификацию I2CP Send Message Expires для подробностей.
Будущая работа
Примечание: ElGamal/AES+SessionTags заменяется на ECIES-X25519-AEAD-Ratchet (Предложение 144). Проблемы и идеи, упомянутые ниже, были включены в дизайн нового протокола. Следующие пункты не будут решены в ElGamal/AES+SessionTags.
Существует множество возможных областей для настройки алгоритмов Session Key Manager; некоторые из них могут взаимодействовать с поведением библиотеки потоков или оказывать значительное влияние на общую производительность.
Количество доставленных тегов может зависеть от размера сообщения, учитывая окончательное дополнение до 1КБ на уровне tunnel сообщений.
Клиенты могли бы отправлять router’у оценку времени жизни сессии в качестве рекомендации по количеству необходимых тегов.
Доставка слишком малого количества тегов приводит к тому, что router переключается на затратное шифрование ElGamal.
Router может предполагать доставку Session Tags или ожидать подтверждения перед их использованием; каждая стратегия имеет свои компромиссы.
Для очень коротких сообщений почти все 222 байта полей pre-IV и padding в блоке ElGamal могут быть использованы для всего сообщения вместо установки сессии.
Оценить стратегию заполнения; в настоящее время мы заполняем до минимума 128 байт. Было бы лучше добавить несколько тегов к небольшим сообщениям, чем заполнять.
Возможно, система Session Tag могла бы быть более эффективной, если бы она была двунаправленной, чтобы теги, доставляемые по ‘прямому’ пути, могли использоваться в ‘обратном’ пути, тем самым избегая ElGamal в начальном ответе. В настоящее время router применяет подобные трюки при отправке тестовых сообщений tunnel самому себе.
Изменение от Session Tags к синхронизированному PRNG .
Несколько из этих идей могут потребовать нового типа сообщения I2NP, или установки флага в Инструкциях доставки , или установки магического числа в первых нескольких байтах поля Session Key и принятия небольшого риска совпадения случайного Session Key с магическим числом.