Третья часть перевода официальной документации I2P.
Ещё ближе к тексту.
Если кто-то не в курсе, то добро пожаловать под кат, читать в порядке оглавления.

Оглавление:
Часть 1: «Всё что вы хотели знать и боялись спросить о I2P»
Часть 2: Туннельная магия, NetDB и «жонглирование» протоколами
Часть 3: Цифровой чеснок

Криптография

Минимальный набор криптографических примитивов складываются для обеспечения в I2P многоуровневой защиты от различных угроз.На самом нижнем уровне взаимодействие между маршрутизаторами защищено на транспортном уровне (TLS). Для этого используется протокол SSU (secure semireliable UDP), согласно которому каждый пакет зашифровывается при помощи AES256 в CBC режиме с явным указанием вектора инициализации (IV) и кода аутентичности сообщения (по протоколу 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.