Garlic Routing и терминология “Garlic”
Термины “garlic routing” и “garlic encryption” часто используются довольно свободно при упоминании технологии I2P. Здесь мы объясняем историю этих терминов, их различные значения и использование методов “garlic” в I2P.
Термин “Garlic routing” был впервые введён Майклом Дж. Фридманом в магистерской диссертации Master’s thesis Роджера Дингледайна Free Haven, раздел 8.1.1 (июнь 2000 г.), как развитие концепции Onion Routing .
“Garlic” мог быть изначально использован разработчиками I2P потому, что I2P реализует форму объединения, как описывает Фридман, или просто для подчеркивания общих отличий от Tor. Конкретная причина может быть утеряна в истории. В целом, при упоминании I2P термин “garlic” может означать одну из трех вещей:
- Многоуровневое шифрование
- Объединение множественных сообщений вместе
- ElGamal/AES шифрование
К сожалению, использование терминологии “garlic” в I2P на протяжении последних лет не всегда было точным; поэтому читателю следует быть осторожным при встрече с этим термином. Надеемся, что приведенное ниже объяснение внесет ясность.
Многослойное шифрование
Onion routing — это техника построения маршрутов, или туннелей, через серию узлов с последующим использованием этого туннеля. Сообщения многократно шифруются отправителем, а затем расшифровываются каждым промежуточным узлом. На этапе построения каждому узлу открываются только инструкции маршрутизации для следующего узла. На этапе работы сообщения передаются через туннель, и сообщение с его инструкциями маршрутизации открываются только конечной точке туннеля.
Это похоже на то, как Mixmaster (см. сравнение сетей ) отправляет сообщения - берет сообщение, шифрует его открытым ключом получателя, берет это зашифрованное сообщение и шифрует его (вместе с инструкциями, указывающими следующий переход), затем берет полученное зашифрованное сообщение и так далее, пока не получится один уровень шифрования для каждого перехода вдоль маршрута.
В этом смысле “garlic routing” как общая концепция идентична “onion routing”. Как реализовано в I2P, конечно, есть несколько отличий от реализации в Tor; см. ниже. Тем не менее, есть существенные сходства, благодаря которым I2P получает пользу от большого объема академических исследований onion routing , Tor и подобных mixnet .
Объединение нескольких сообщений
Майкл Фридман определил “garlic routing” как расширение onion routing, при котором несколько сообщений объединяются вместе. Он назвал каждое сообщение “луковицей”. Все сообщения, каждое со своими собственными инструкциями доставки, раскрываются в конечной точке. Это позволяет эффективно объединять “блок ответа” onion routing с исходным сообщением.
Эта концепция реализована в I2P, как описано ниже. Наш термин для garlic “луковиц” — это “дольки”. Может содержаться любое количество сообщений, а не только одно сообщение. Это существенное отличие от onion routing, реализованного в Tor. Однако это лишь одно из многих крупных архитектурных различий между I2P и Tor; возможно, само по себе оно недостаточно для обоснования смены терминологии.
Еще одно отличие от метода, описанного Фридманом, заключается в том, что путь является однонаправленным - здесь нет “точки поворота”, как в onion routing или блоках ответов mixmaster, что значительно упрощает алгоритм и обеспечивает более гибкую и надежную доставку.
Шифрование ElGamal/AES
В некоторых случаях “garlic encryption” может просто означать шифрование ElGamal/AES+SessionTag (без множественных слоёв).
Методы “Garlic” в I2P
Теперь, когда мы определили различные термины “garlic”, мы можем сказать, что I2P использует garlic routing, объединение и шифрование в трех местах:
- Для построения и маршрутизации через tunnel’ы (многослойное шифрование)
- Для определения успеха или неудачи доставки сообщений от конца до конца (объединение в пакеты)
- Для публикации некоторых записей сетевой базы данных (снижение вероятности успешной атаки анализа трафика) (ElGamal/AES)
Также существуют значительные способы использования этой техники для улучшения производительности сети, используя компромиссы между задержкой/пропускной способностью транспорта и ветвление данных через резервные пути для повышения надежности.
Создание tunnel’ов и маршрутизация
В I2P tunnel являются однонаправленными. Каждая сторона строит два tunnel — один для исходящего и один для входящего трафика. Поэтому для одного сообщения туда-обратно и ответа требуется четыре tunnel.
Tunnel строятся и затем используются с многослойным шифрованием. Это описано на странице реализации tunnel . Мы используем ElGamal/AES+SessionTag для шифрования.
Туннели представляют собой универсальный механизм для транспортировки всех I2NP сообщений , и Garlic Messages не используются для построения туннелей. Мы не объединяем несколько I2NP сообщений в одно Garlic Message для распаковки на конечной точке исходящего туннеля; шифрования туннеля достаточно.
Сквозное объединение сообщений
На уровне выше tunnel I2P доставляет сообщения между Destinations от конца до конца. Как и внутри одного tunnel, мы используем ElGamal/AES+SessionTag для шифрования. Каждое клиентское сообщение, доставленное в router через интерфейс I2CP , становится единственным Garlic Clove со своими собственными инструкциями доставки внутри Garlic Message. Инструкции доставки могут указывать Destination, Router или Tunnel.
Как правило, Garlic Message будет содержать только один clove. Однако router будет периодически объединять два дополнительных clove в Garlic Message:
Сообщение о статусе доставки с инструкциями доставки, указывающими, что оно должно быть отправлено обратно к исходному router в качестве подтверждения. Это аналогично “блоку ответа” или “луковице ответа”, описанным в справочных материалах. Используется для определения успеха или неудачи доставки сообщений от конца до конца. Исходный router может, при неполучении сообщения о статусе доставки в ожидаемый период времени, изменить маршрутизацию к удаленному назначению или предпринять другие действия.
Сообщение Database Store, содержащее LeaseSet для исходящего Destination, с инструкциями доставки, указывающими router удаленного назначения. Периодически включая LeaseSet, router гарантирует, что удаленная сторона сможет поддерживать связь. В противном случае удаленной стороне пришлось бы запрашивать floodfill router для получения записи из сетевой базы данных, и все LeaseSet пришлось бы публиковать в сетевой базе данных, как объясняется на странице сетевой базы данных .
По умолчанию сообщения Delivery Status и Database Store объединяются в пакеты при изменении локального LeaseSet, при доставке дополнительных Session Tags или если сообщения не были объединены в пакеты в течение предыдущей минуты.
Очевидно, что дополнительные сообщения в настоящее время объединяются для конкретных целей и не являются частью универсальной схемы маршрутизации.
Начиная с версии 0.9.12, сообщение о статусе доставки оборачивается в другое Garlic Message отправителем, чтобы содержимое было зашифровано и не видно роутерам на обратном пути.
Хранение в базе данных сети Floodfill
Как объясняется на странице базы данных сети , локальные LeaseSets отправляются на floodfill роутеры в сообщении Database Store Message, завёрнутом в Garlic Message, чтобы оно не было видимо исходящему шлюзу туннеля.
Будущая работа
Механизм Garlic Message очень гибкий и предоставляет структуру для реализации многих типов методов доставки mixnet. Вместе с неиспользуемой опцией задержки в инструкциях доставки tunnel message, возможен широкий спектр стратегий группировки, задержки, смешивания и маршрутизации.
В частности, существует потенциал для гораздо большей гибкости на конечной точке исходящего tunnel. Сообщения потенциально могут маршрутизироваться оттуда в один из нескольких tunnel (таким образом минимизируя прямые соединения), или передаваться multicast в несколько tunnel для избыточности, или для потокового аудио и видео.
Такие эксперименты могут противоречить необходимости обеспечения безопасности и анонимности, например, ограничению определенных маршрутов, ограничению типов I2NP сообщений, которые могут пересылаться по различным путям, и принудительному применению определенного времени истечения срока действия сообщений.
Как часть шифрования ElGamal/AES, garlic сообщение содержит определяемое отправителем количество данных заполнения, что позволяет отправителю предпринимать активные контрмеры против анализа трафика. В настоящее время это не используется, за исключением требования дополнения до кратного 16 байтам.
Шифрование дополнительных сообщений к и от floodfill routers .
Ссылки
- Термин garlic routing был впервые введен в магистерской диссертации Роджера Динглдайна для Free Haven (июнь 2000), см. Раздел 8.1.1, написанный Майклом Дж. Фридманом .
- Публикации Onion Router
- Onion Routing (Википедия)
- Garlic Routing (Википедия)
- Проект Tor
- Free Haven Anonbib
- Onion routing впервые был описан в работе Hiding Routing Information Дэвидом М. Гольдшлагом, Майклом Г. Ридом и Полом Ф. Сайверсоном в 1996 году.