Третья часть перевода официальной документации I2P.
Ещё ближе к тексту.
Если кто-то не в курсе, то добро пожаловать под кат, читать в порядке оглавления.
Оглавление:
Часть 1: «Всё что вы хотели знать и боялись спросить о I2P»
Часть 2: Туннельная магия, NetDB и «жонглирование» протоколами
Часть 3: Цифровой чеснок
Криптография
Минимальный набор криптографических примитивов складываются, чтобы обеспечить в I2P многоуровневую защиту от различных угроз.
На самом низком уровне, связь между роутерами защищена с использованием SSU, который шифрует каждый пакет, с использованием AES256/CBC, в качестве открытого ключа для IV (уровня) используется MAC (HMAC-MD5-128), после согласования генерируется временный ключ 2048 бит по алгоритму Диффи-Хеллмана. Между станциями аутентификация проходит с использованием DSA ключа, плюс каждое сетевое сообщение имеет своё собственный хеш, для проверки целостности при обмене между маршрутизаторами.
Туннельные сообщения передаются на уровне с AES256/CBC с открытым ключом IV и проверенной целью, с дополнительным SHA256 хеш’ом. Другие сообщения так же проходят через сеть внутри чеснока, но зашифрованные с использованием алгоритмов Эль-Гемаля(ElGamal)/AES + SessionTags (см. ниже).
“Честночные сообщения”
Честночные сообщения, являются продолжением лукового («onion») шифрования, позволяет содержать в одном сообщении множество вложений («cloves»), которые являются полностью сформированными сообщениями со своими инструкциями к доставке. Сообщения заворачиваются в чеснок каждый раз, когда отправляются куда либо, в противном случае их содержимое будет видно посредническим узлам, а это не допустимо. В качестве примера, следующая ситуация:
Роутер, отправляет запрос другому роутеру, для участия в создании туннеля, для этого он оборачивает сообщение в “чеснок” зашифровывает получая открытый ключ 2048 бит, по схеме Эль-Гамаля и отправляет сообщение через туннель.
Другой пример, когда клиент хочет отправить сообщение получателю, роутер “отправителя” будет заворачивать данные сообщения (на ряду с другими сообщениями) в чеснок, шифровать чеснок с использованием 2048 битного открытого ключа по схеме Эль-Гамаля, опубликованного в leaseSet получателя и отправлять его через соответствующий туннель.
Инструкции вложенные содержащиеся в дольках, дают возможность перенаправить локально (куда-либо), на удалённый роутер или в туннель к удалённому роутеру. В инструкциях есть специальные поля, позволяющие просить пиров отложить доставку до срабатывания определённого триггера (по времени или условию), если они не будут выполнены в пределах “нетривиальных задержек” (искусственно созданные задержки), то сообщение будет “развёрнуто” (are deployed).
Если возможно, то чесночное сообщение может быть отправлено через любое количество hops (прыжков — промежуточных точек), без построенного в заранее туннеля, до цели. Находясь в чесноке оно пройдёт заданное количество шагов, до доставки на следующий hop в туннеле.
(прим. пер. — как я понимаю, это и есть пример нетривиальной задержки).
В текущей реализации сети и клиента, этот метод недоступен.
Сессионные теги
Как ненадежны и неупорядоченны сообщения системы основанной на I2P, I2P использует простую комбинацию асимметричных и симметричных алгоритмов шифрования, чтобы обеспечить конфиденциальность и целостность данных вложенных в чесночные сообщения. Это сочетание обозначается как Эль-Гемаль/AES+SessionTags, но это излишне подробный способ описания использованных простых алгоритмов 2048 битового “ElGamal”, AES256, SHA256 и 32 байтного одноразового номера.
Сначала роутер шифрует сообщение для другого роутера посредством AES256, в качестве ключа служит ElGamal и после него добавляется AES256/CBC шифрованная “полезная” (Дополнительная, транзитная) нагрузка. В дополнительной нагрузке, в зашифрованной AES секции содержится длинна нагрузки, SHA256 хеш, не шифрованной нагрузки и ряд сессионный тег — случайные 32 байта. В следующий раз, отправитель захочет зашифровать “чеснок” для другого роутера, но без генерации по ElGamal нового ключа, он просто может выбрать один из ранее поставленных сессионных тегов и AES шифрования полезной нагрузки, как и прежде, с помощью ключа использующего сессионный тег, который был добавлен до этого. Когда роутер получает сообщение, он проверяет первые 32 байта, чтобы узнать совпадают ли они с доступными сессионными тегами, если совпадают, то используется простая дешифровка AES, но если нет, то для первого блока используется алгоритм ElGamal.
Каждый сессионный тег, может быть использован только один раз, для предотвращения внутренних конфликтов и из необходимости корреляции сообщений между маршрутизаторами. Чесночные сообщения позволяют контролировать состояние доставки, если доставка успешна, то выполняется триггер:
Попадание к получателю -> успешная дешифровка -> поиск инструкции для обратного ответа, если найдена отправить ответ, по входящему туннелю обратно к отправителю.
Когда отправитель получает сообщение о статусе доставки, он узнаёт, что сессионный тег в сообщении было успешно доставлены. Сессионные теги, сами по себе живут очень мало, после выхода срока жизни они удаляются, если не используются. Кроме того, количество сохранений для каждого ключа ограничено, ровно как и число самих ключей. Если тегов слишком много, то новые или старые могут быть “выкинуты”. Отправитель отслеживает свои сообщения с помощью тегов сессии, если нет необходимой связи они могут быть удалены перед тем, как сообщение будет раскрыто и сообщение вернётся назад благодаря дорожке из Эль-Гамаля шифрования.
(прим. пер: PRNG — Псевдо случайный генератор чисел)
Одним из вариантов является отправка, одного тега и прослушивание PRNG для определения, какие теги использовались и какие могут быть использованы.
Поддерживая PRNG примерно синхронизированным между отправителем и получателем (получателем предварительно вычисляется размер следующего окна, например в 50 тегов), при слишком больших накладных расходах, теги удаляются что позволяет получить больше вариантов и получить компромисс между временем и объёмом, и сокращение количества ElGamal шифрований.
Тем не менее, от силы PRNG будет зависеть степень защиты от внутренних противников, возможно путём ограничения количество использований PRNG, любые слабости могут быть минимизированны. Но на данный момент, в обозримом будущем, нет планов двигаться в сторону развития синхронного PRNG.
Автор: nefelim4ag
