i2pd-tools: дополнительные утилиты I2P

Подробное изучение i2pd достойно уважения. Эта статья близка по духу навыкам администрирования роутера, но посвящена несколько другой, но важной теме: набору инструментов, который включает в себя ряд полезных утилит. i2pd-tools, дамы и господа!

1. keygen – генерация ключей

2. vain – генерация ключей по шаблону (майнер красивых адресов)

3. keyinfo – информация о ключах

4. b33address – получение адреса для зашифрованного лизсета

5. regaddr – регистрация короткого домена в зоне .i2p

6. regaddr_3ld – регистрация домена третьего уровня в зоне .i2p

7. regaddralias – привязка короткого домена к новым ключам

8. offlinekeys – использование временных ключей в целях безопасности

9. routerinfo – информация о роутере

10. x25519 – генерация ключей шифрования

11. i2pbase64 – кодирование информации в base64 и ее декодирование

Компиляция утилит

Как обычно, все интересное ждет в официальном гит-репозитории. В корне присутствует англоязычное описание с краткими и чаще всего понятными инструкциями, но на то она и статья: сейчас о том же самом, но подробнее и на русском языке.

Начнем со сборки бинарных файлов: для начала скачайте репозиторий к себе на устройство. Команда клонирования на всех операционных системах выглядит одинаково: git clone --recursive https://github.com/purplei2p/i2pd-tools. Чтобы установить зависимости, необходимо запустить скрипт dependencies.sh. Предполагается, что компилятор C++ и программа сборки make уже имеются, поэтому под зависимостями понимаются исключительно библиотеки boost и openssl.

Если вы только начинаете путь на поприще со сборкой программ из исходных кодов, поставьте git, компилятор g++ и систему сборки make командой вроде этой: sudo apt install git g++ make. Для пользователей Windows все немного сложнее – требуется установить оболочку MSYS2, а затем из нее выполнить команду: pacman -S git make mingw-w64-x86_64-gcc. Скрипт для установки зависимостей также запускается в MSYS2 (если скрипт не хочет запускаться, нужно сделать его исполняемым простой командой chmod +x dependencies.sh). Когда все готово, запускаем сборку командой make.

Хорошая новость: с недавних пор для Windows публикуются готовые бинарные файлы, поэтому, если ручная сборка кажется неприподъемной задачей, воспользуйтесь ими.

keygen

При указании несуществующих ключей в конфигурационном файле туннелей, автоматически создаются новые. В большинстве случаев это удобно. Однако, если требуется заранее знать адрес, либо произвести какие-то дополнительные манипуляции с ключом, следует воспользоваться утилитой keygen. Использование крайне простое: запускаем keygen с указанием желаемого имени для новых ключей. По умолчанию используется актуальный тип подписи EDDSA-SHA512-ED25519 (кодовое обозначение 7), который также является типом по умолчанию при создании ключей самим I2P-роутером. Если требуется получить ключ с другим типом подписи, его следует указать при запуске после имени файла. Можно указать как имя типа, так и его номер. Обозначения приведены в файле README.

vain

Крайне редко можно увидеть хоть сколько-то читаемый адрес в выдаче keygen (потому что это просто хеш). Для адресов с человекочитаемым началом существует отдельная утилита vain (vanitygen). Говорящее название (vanity – «тщеславие») намекает на основное применение майнера адресов. Конечно помимо тщеславия адрес с запоминающимся началом имеет и практический профит: его проще распознать на глаз.

При запуске без параметров видим информацию об использовании. Поиск по строковому паттерну всегда осуществляется с начала адреса. Если нужен более гибкий поиск, или не с начала строки, стоит воспользоваться регулярными выражениями. Учтите, что поиск по регулярному выражению медленнее, чем по обычному строковому значению. Количество потоков по умолчанию совпадает с количеством ядер компьютера, но может быть вручную задано через параметр -t (--threads).

Шаблоны до 6 символов находятся почти моментально, но с увеличением строки поиска время растет экспоненциально. Небольшая табличка с примерным временем нахождения приведена в файле README. На момент выхода статьи vain поддерживает только ключи с типом подписи EDDSA-SHA512-ED25519 (7), используемый в сети по умолчанию.

keyinfo

Веб-консоль i2pd не всегда удобно использовать для получения информации о ключах. В первую очередь потому, что в ней отображаются только используемые в настоящий момент приватные ключи. Во-вторых, предоставляется не исчерпывающая информация о ключах. Например, нет явного указания типа шифрования и подписи.

Возможные параметры: -v – от «verbose», подробный вывод; -d – от «destination», вывод только полного адреса в кодировке base64, -b – от «b33» («bb32»), вывод адреса для зашифрованного лизсета (подробно о зашифрованных лизсетах читайте в статье).

При передаче приватного ключа без дополнительных параметров, выводится его внутрисетевой адрес (домен). При подробном выводе отображается полный адрес (набор всех криптографических идентификаторов).

Обратите внимание на поле «Destination Hash». Это ежедневно изменяемое значение, по которому конечная точка выбирает место для публикации информации о себе, а клиент – определяет флудфил, к которому нужно за этим адресом обратиться. Подробнее о том, как хеш хранения адреса меняется каждый день и почему это критически важно с точки зрения безопасности, читайте в более ранней статье.

b33address

keyinfo с флагом -b высчитывает адрес для конечной точки с зашифрованным лизсетом. b33address делает то же самое, но принимает не файл с ключами, а полный адрес в кодировке base64. Для использования зашифрованных лизсетов (которые называются b33 или bb32, что одно и то же), рекомендуется использовать тип подписи 11. Утилита b33address работает только с ним.

На скриншоте генерируется ключ, затем его адрес bb32 запрашивается через keyinfo. Чтобы получить полный адрес, снова используется keyinfo. Вывод keyinfo был скопирован, а затем передан в b33address. Утилита сообщила адрес, который будет использован при зашифрованном лизсете, а также вывела сегодняшний хеш хранения. Как видно, значения совпадают с теми, которые предоставила утилита keyinfo, т.е. функционал b33address аналогичен keyinfo -b, но отличается форматом принимаемого значения.

regaddr

Для регистрации коротких человекочитаемых доменов вроде «site.i2p» необходимо посетить регистраторы reg.i2p и stats.i2p (первый – от русскоязычного сообщества PurpleI2P, второй – от англоязычной команды Java-роутера).

Оба регистратора работают по схожему принципу: вы предоставляете свой полный адрес, к которому будет привязан желаемый домен, а также криптографическую подпись заявленного желания. Подпись проверяется ключом из полного адреса. Такая заявка имеет стандартный вид и генерируется утилитой regaddr (с версии 2.37.0 i2pd поддерживает генерацию регистрационной строки через веб-консоль). Синтаксис утилиты простой: сначала файл с ключами, затем желаемый домен.

Работа утилиты regaddr проста, как и синтаксис регистрационной строки: сначала идет желаемый домен, затем полный адрес, к которому он будет привязан, а в конце строки – подпись желаемого домена. Синим цветом на скриншоте выделен полный адрес. Для наглядности полный адрес также получен утилитой keyinfo с флагом -d. Красным цветом выделена подпись.

Получая подобную строку, регистратор проверяет валидность подписи и, если заявленный домен свободен, регистрирует его. Для примера можно воспользоваться утилитой verifyhost, которую использует reg.i2p. При использовании в bash необходимо экранировать восклицательный знак, чтобы он был интерпретирован как часть строки, и передан в утилиту (либо заключить всё выражение в ковычки).

Подпись верна, поэтому verifyhost не выдал ошибок и вернул значение, равное нулю.

regaddr_3ld

В I2P поддерживаются человекочитаемые домены третьего уровня. Их регистрация происходит аналогичным образом, но строка генерируется чуть сложнее – в три шага. Генерация регистрационной строки для домена третьего уровня невозможна через веб-консоль и реализуется исключительно через утилиту regaddr_3ld.

Сначала ключом субдомена подписывается желаемый домен третьего уровня:

./regaddr_3ld step1 sub_domain.dat sub.domain.i2p > step1.txt

Затем ключом основного домена подписывается строка субдомена:

./regaddr_3ld step2 step1.txt domain.dat domain.i2p > step2.txt

В завершение подписанная ключом основного домена заявка на домен третьего уровня подписывается ключом домена третьего уровня:

./regaddr_3ld step3 step2.txt sub_domain.dat > step3.txt

В приведенном примере регистрационная строка находится в файле step3.txt.

regaddralias

Для смены ключей, к которым привязан короткий домен, воспользуйтесь утилитой regaddralias. Для реализации возможности необходимо, чтобы у вас на руках были старые ключи (а не только новые). В программу передается имя файла с новыми ключами, файл со старыми ключами и сам домен последним параметром.

На скриншоте выделены ключевые слова алиаса перепривязки домена к новым ключам: задается новый полный адрес с указанием прежнего полного адреса и ко всему этому прикладываются подписи.

offlinekeys

I2P имеет концепцию оффлайн-ключей (offline keys), которая позволяет хранить постоянные ключи в надежном месте. Другими словами, основной ключ хранится в безопасном месте, а на сервере используется временный, срок действия которого истекает через заданное количество дней. В случае его компрометации, спустя заданный срок действия, вы с полной уверенностью можете утверждать, что ваш сетевой адрес снова принадлежит только вам. Оффлайн-ключи подробно разобраны в отдельной статье.

На скриншоте красным цветом выделен основной ключ и его адрес, а синим – временный ключ, который имеет пометку «Offline signature» и тот же адрес.

routerinfo

I2P-роутер складывает информацию об известных роутерах в директорию netDb. Затем эти роутеры используются при построении транзитных туннелей. Файл, являющийся идентификатором роутера, называется RouterInfo (RI). В него включается информация о криптографических ключах и IP-адрес (если он публикуется и является доступным извне).

Флаг -p отображает порт (по умолчанию выводится только IP-адрес). Флаг -f выводит правило для файервола iptables для разрешения исходящего подключения к конкретному I2P-роутеру (для параноидальных случаев, когда все исходящие соединения запрещены). Параметр -6 добавляет в выдачу IPv6 адрес, если он присутствует.

x25519

Утилита для генерации пары ключей шифрования x25519, выводящая результат в кодировке base64. На момент выхода статьи используется в зашифрованных лизсетах с авторизацией.

i2pbase64

Почти в каждом пункте этой статьи упоминалась какая-либо информация, которая по умолчанию является бинарной (двоичным, нечитаемым машинным кодом). Например, криптографические ключи и хеши. Чтобы двоичную информацию было проще воспринимать человеку, а также легко передавать в текстовом виде, в I2P почти повсеместно используется кодировка base64. Алфавит base64 в I2P отличается от общего стандарта на два символа: + заменяется на -, а / на ~. Это связано с использованием base64-строк в веб-браузере, где + и / являются специальными символами: человекочитаемые короткие домены записываются в локальную базу роутера через браузер посредством открытия специальных ссылок (addresshelper).

На скриншоте приведен пример кодирования текстовой информации, а затем ее раскодирование обратно в текст. Утилита аналогичным образом работает с любыми бинарными файлами вроде изображений или видео. Прямое практическое назначение у i2pbase64 в i2pd-tools отсутствует. Это сугубо специфичная утилита для экзотических задач, например, ручного кодирования сторонних ключей.

Утилита famtool не была освещена в статье по простой причине: family – дополнительный опознавательный признак роутера. В концепции, в которую поверили лишь единицы, в том числе zzz (ведущий разработчик Java-роутера), family указывается добропорядочными пользователями для того, чтобы роутеры одного админа не появились вместе в одном туннеле. Как не трудно понять, эта опция никем и никогда не используется, а злонамеренными людьми, которые хотят захватывать как можно больше туннелей для попытки мониторинга сети, – family не используется тем более. При практической бессмысленности, инструмент famtool не тривиален в использовании, поэтому в рамках этого материала упущен.

Оригинальная статья опубликована в блоге дата-центра ITSOFT.