Статус
Реализовано в версии 0.9.57.
Оставляем это предложение открытым, чтобы мы могли улучшать и обсуждать идеи из раздела «Планирование на будущее».
Обзор
Краткое содержание
Открытый ключ ElGamal в Destination не используется с версии 0.6 (2005).
Хотя в наших спецификациях действительно указано, что он не используется, в них НЕ указано, что реализации могут не генерировать пару ключей ElGamal и просто заполнять это поле случайными данными.
Мы предлагаем изменить спецификации, указав, что
поле игнорируется и реализации МОГУТ заполнять его случайными данными.
Это изменение обратно совместимо. Неизвестно ни одной реализации, которая проверяла бы открытый ключ ElGamal.
Кроме того, это предложение даёт рекомендации разработчикам по генерации
случайных данных для заполнения поля в Destination и Router Identity, чтобы они были сжимаемыми,
оставаясь при этом безопасными, и чтобы их представление в Base64 не выглядело повреждённым или небезопасным.
Это даёт большую часть преимуществ от удаления полей заполнения без каких-либо
нарушительных изменений протокола.
Сжимаемые Destination уменьшают размер streaming SYN и repliable datagram;
сжимаемые Router Identity уменьшают размер Database Store Messages, сообщений SSU2 Session Confirmed
и reseed-файлов su3.
Наконец, в предложении рассматриваются возможности новых форматов Destination и Router Identity,
которые полностью устранят необходимость в заполнении. Также кратко обсуждается постквантовая
криптография и её возможное влияние на будущее планирование.
Цели
- Устранить необходимость генерации пары ключей ElGamal для Destination
- Рекомендовать лучшие практики, чтобы Destination и Router Identity были хорошо сжимаемыми,
но не содержали очевидных шаблонов в представлении Base64 - Поощрять принятие лучших практик всеми реализациями, чтобы поля не были различимы
- Уменьшить размер streaming SYN
- Уменьшить размер repliable datagram
- Уменьшить размер блока RI в SSU2
- Уменьшить размер и частоту фрагментации сообщений SSU2 Session Confirmed
- Уменьшить размер Database Store Message (с RI)
- Уменьшить размер reseed-файлов
- Сохранить совместимость во всех протоколах и API
- Обновить спецификации
- Обсудить альтернативы для новых форматов Destination и Router Identity
Устранив необходимость генерации ключей ElGamal, реализации могут
смочь полностью удалить код ElGamal, с учётом соображений обратной совместимости
в других протоколах.
Дизайн
Строго говоря, одного 32-байтового открытого ключа подписи (в Destination и Router Identity)
и 32-байтового открытого ключа шифрования (только в Router Identity) —
случайного числа — достаточно, чтобы хэши SHA-256 этих структур
были криптографически стойкими и равномерно распределёнными в DHT сети.
Однако из предосторожности мы рекомендуем использовать минимум 32 байта случайных данных
в поле открытого ключа ElGamal и в полях заполнения. Кроме того, если бы поля были заполнены нулями,
Base64-представления Destination содержали бы длинные последовательности символов AAAA,
что может вызвать тревогу или недоумение у пользователей.
Для типа подписи Ed25519 и типа шифрования X25519:
Destination будет содержать 11 копий (352 байта) случайных данных.
Router Identity будет содержать 10 копий (320 байт) случайных данных.
Оценка экономии
Destination включаются в каждый streaming SYN
и repliable datagram.
Router Infos (содержащие Router Identity) включаются в Database Store Messages
и в сообщения Session Confirmed в NTCP2 и SSU2.
NTCP2 не сжимает Router Info.
RI в Database Store Messages и сообщениях SSU2 Session Confirmed сжимаются gzip.
Router Infos сжимаются в reseed-файлах SU3.
Destination в Database Store Messages не сжимаются.
Сообщения streaming SYN сжимаются на уровне I2CP.
Для типа подписи Ed25519 и типа шифрования X25519
оценочная экономия:
| Тип данных | Общий размер | Ключи и сертификаты | Несжатое заполнение | Сжатое заполнение | Размер | Экономия |
|---|---|---|---|---|---|---|
| Destination | 391 | 39 | 352 | 32 | 71 | 320 байт (82%) |
| Router Identity | 391 | 71 | 320 | 32 | 103 | 288 байт (74%) |
| Router Info | 1000 тип. | 71 | 320 | 32 | 722 тип. | 288 байт (29%) |
Примечания: Предполагается, что 7-байтовый сертификат несжимаем, дополнительные накладные расходы gzip отсутствуют.
Ни то, ни другое не совсем верно, но эффект будет незначительным.
Игнорируются другие сжимаемые части Router Info.
Спецификация
Предлагаемые изменения в текущие спецификации документируются ниже.
Общие структуры
Изменить спецификацию общих структур,
указав, что 256-байтовое поле открытого ключа Destination игнорируется и может
содержать случайные данные.
Добавить раздел в спецификацию общих структур,
рекомендующий лучшую практику для поля открытого ключа Destination и полей заполнения
в Destination и Router Identity, следующим образом:
Сгенерируйте 32 байта случайных данных с использованием надёжного криптографического генератора псевдослучайных чисел (PRNG)
и повторите эти 32 байта столько раз, сколько необходимо, чтобы заполнить поле открытого ключа (для Destination)
и поле заполнения (для Destination и Router Identity).
Файл приватного ключа
Формат файла приватного ключа (eepPriv.dat) не является официальной частью наших спецификаций,
но задокументирован в Java I2P javadocs
и поддерживается другими реализациями.
Это обеспечивает переносимость приватных ключей между различными реализациями.
Добавить примечание в эти javadoc, что открытый ключ шифрования может быть случайным заполнением,
а приватный ключ шифрования может быть нулевым или случайными данными.
SAM
Указать в спецификации SAM, что приватный ключ шифрования не используется и может игнорироваться.
Клиент может возвращать любые случайные данные.
SAM Bridge может отправлять случайные данные при создании (с DEST GENERATE или SESSION CREATE DESTINATION=TRANSIENT),
вместо заполнения нулями, чтобы представление в Base64 не содержало строку символов AAAA
и не выглядело повреждённым.
I2CP
Изменения в I2CP не требуются. Приватный ключ для открытого ключа шифрования в Destination
не отправляется маршрутизатору.
Планирование на будущее
Изменения протокола
Со стоимостью изменения протокола и потерей обратной совместимости мы могли бы
изменить наши протоколы и спецификации, чтобы устранить поле заполнения в
Destination, Router Identity или в обоих.
Это предложение имеет сходство с форматом «b33» зашифрованного leaseset,
содержащего только поле ключа и типа.
Для сохранения некоторой совместимости определённые уровни протокола могли бы «расширять» поле заполнения
нулями для представления другим уровням протокола.
Для Destination мы также могли бы удалить поле типа шифрования в сертификате ключа,
с экономией в два байта.
Альтернативно, Destination могли бы получить новый тип шифрования в сертификате ключа,
указывающий на нулевой открытый ключ (и заполнение).
Если преобразование совместимости между старыми и новыми форматами не будет включено на каком-либо уровне протокола,
будут затронуты следующие спецификации, API, протоколы и приложения:
- Спецификация общих структур
- I2NP
- I2CP
- NTCP2
- SSU2
- Ratchet
- Streaming
- SAM
- Bittorrent
- Reseeding
- Файл приватного ключа
- Java core и API маршрутизатора
- i2pd API
- Библиотеки сторонних SAM
- Встроенные и сторонние инструменты
- Несколько Java-плагинов
- Пользовательские интерфейсы
- P2P-приложения, например MuWire, bitcoin, monero
- hosts.txt, addressbook и подписки
Если преобразование будет определено на каком-либо уровне, список будет короче.
Стоимость и преимущества этих изменений пока неясны.
Конкретные предложения — TBD:
PQ-ключи
Открытые ключи постквантового (PQ) шифрования для любого ожидаемого алгоритма
превышают 256 байт. Это устранит любое заполнение и любую экономию от предложенных выше изменений
для Router Identity.
В «гибридном» PQ-подходе, как это делает SSL, PQ-ключи будут только эфемерными
и не появятся в Router Identity.
PQ-ключи подписи нежизнеспособны,
а Destination не содержат открытых ключей шифрования.
Статические ключи для ratchet находятся в Lease Set, а не в Destination.
поэтому мы можем исключить Destination из дальнейшего обсуждения.
Таким образом, PQ затрагивает только Router Infos, и только при использовании статических (не эфемерных) PQ-ключей, а не гибридных.
Это потребует нового типа шифрования и повлияет на NTCP2, SSU2,
а также на зашифрованные сообщения Database Lookup и ответы.
Ориентировочные сроки разработки, создания и внедрения — ????????
Но это будет после внедрения гибридного или ratchet-подхода ????????????
Для дальнейшего обсуждения см. эту тему .
Проблемы
Может быть желательно медленное переформирование ключей сети, чтобы обеспечить прикрытие для новых маршрутизаторов.
«Переформирование ключей» может означать просто изменение заполнения, а не реальную смену ключей.
Невозможно переформировать существующие Destination.
Следует ли идентифицировать Router Identity с заполнением в поле открытого ключа с помощью другого
типа шифрования в сертификате ключа? Это вызовет проблемы совместимости.
Миграция
Нет проблем с обратной совместимостью при замене ключа ElGamal на заполнение.
Переформирование ключей, если будет реализовано, будет аналогично тому, что было сделано
при трёх предыдущих переходах маршрутизаторов:
с DSA-SHA1 на ECDSA-подписи, затем на
EdDSA-подписи, затем на шифрование X25519.
С учётом проблем обратной совместимости и после отключения SSU,
реализации могут полностью удалить код ElGamal.
Примерно 14% маршрутизаторов в сети используют тип шифрования ElGamal, включая многие floodfill.
Черновой запрос на слияние для Java I2P находится по адресу git.idk.i2p .