Статус
Реализовано в 0.9.57. Оставляем это предложение открытым, чтобы мы могли улучшить и обсудить идеи в разделе “Планирование на будущее”.
Обзор
Резюме
Открытый ключ ElGamal в Destinations не использовался с версии 0.6 (2005). Хотя наши спецификации утверждают, что он не используется, они НЕ заявляют, что реализации могут избегать генерации пары ключей ElGamal и просто заполнять поле случайными данными.
Мы предлагаем изменить спецификации, заявив, что поле игнорируется и реализации МОГУТ заполнять поле случайными данными. Это изменение является обратимо совместимым. Нет известной реализации, которая проверяет открытый ключ ElGamal.
Кроме того, это предложение дает рекомендации разработчикам о том, как генерировать случайные данные для дополнения Destination и Router Identity так, чтобы они были сжимаемыми, но при этом безопасными, и не создавали впечатление поврежденных или небезопасных при представлении в виде Base 64. Это обеспечивает большинство преимуществ удаления полей дополнения без каких-либо разрушительных изменений в протоколе. Сжимаемые Destinations уменьшают размер потоковых SYN и подтверждаемых датаграмм; сжимаемые Router Identities уменьшают размер Database Store Messages, SSU2 Session Confirmed сообщений и файлов reseed su3.
Наконец, предложение обсуждает возможности для новых форматов Destination и Router Identity, которые полностью исключат дополнение. Также есть краткое обсуждение постквантовой криптографии и того, как это может повлиять на будущее планирование.
Цели
- Устранить требование на генерацию пары ключей ElGamal для Destinations
- Рекомендовать лучшие практики, чтобы Destinations и Router Identities были высоко сжимаемыми, но не проявляли очевидных шаблонов в представлениях Base 64.
- Поощрять внедрение лучших практик всеми реализациями, чтобы поля не были различимы
- Уменьшить размер потоковых SYN
- Уменьшить размер подтверждаемых датаграмм
- Уменьшить размер блока RI SSU2
- Уменьшить размер и частоту фрагментации SSU2 Session Confirmed
- Уменьшить размер Database Store Message (с RI)
- Уменьшить размер файла reseed
- Обеспечить совместимость во всех протоколах и API
- Обновить спецификации
- Обсудить альтернативы для новых форматов Destination и Router Identity
Исключив требование на генерацию ключей ElGamal, реализации могут полностью удалить код ElGamal, при условии учета обратной совместимости в других протоколах.
Проектирование
Строго говоря, 32-байтный открытый ключ подписи (и в Destinations, и в Router Identities), а также 32-байтный открытый ключ шифрования (только в Router Identities) представляют собой случайное число, которое обеспечивает всю необходимую энтропию для хешей SHA-256 этих структур, чтобы они были криптографически сильными и случайным образом распределенными в сетевой базе данных DHT.
Тем не менее, из соображений осторожности, мы рекомендуем использовать минимум 32 байта случайных данных в поле открытого ключа ElG и дополнении. Кроме того, если бы поля содержали нули, Base 64_DESTINATIONS были бы длинными рядами символов AAAA, что могло бы вызвать тревогу или замешательство у пользователей.
Для типа подписи Ed25519 и типа шифрования X25519: Destinations будут содержать 11 копий (352 байта) случайных данных. Router Identities будут содержать 10 копий (320 байт) случайных данных.
Оценка экономии
Destinations включены в каждый потоковый SYN и подтверждаемую датаграмму. Router Infos (содержащие Router Identities) включены в Database Store Messages и в сообщения Session Confirmed в NTCP2 и SSU2.
NTCP2 не сжимает Router Info. RIs в Database Store Messages и SSU2 Session Confirmed сообщениях сжимаются с использованием gzip. Router Infos сжимаются в файлах reseed SU3.
Destinations в Database Store Messages не сжимаются. Сообщения Streaming SYN сжимаются с использованием gzip на уровне 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 байта, если необходимо, чтобы заполнить поле открытого ключа (для Destinations) и поле дополнения (для Destinations и Router Identities).
Файл закрытого ключа
Формат файла закрытого ключа (eepPriv.dat) не является официальной частью наших спецификаций но он документирован в Java I2P javadocs и другие реализации его поддерживают. Это обеспечивает переносимость закрытых ключей между разными реализациями. Добавьте примечание к этому javadoc, что открытый ключ шифрования может быть случайным дополнением, а закрытый ключ шифрования может быть полностью нулевым или случайными данными.
SAM
Примечание в спецификации SAM, что закрытый ключ шифрования не используется и может быть проигнорирован. Любые случайные данные могут быть возвращены клиентом. SAM Bridge может отправлять случайные данные при создании (с DEST GENERATE или SESSION CREATE DESTINATION=TRANSIENT) вместо одних нулей, чтобы представление в Base 64 не содержало строку из символов AAAA и не выглядело сломанным.
I2CP
Изменения не требуются в I2CP. Закрытый ключ для открытого ключа шифрования в Destination не отправляется маршрутизатору.
Планирование на будущее
Изменения протокола
С учетом затрат на изменения протокола и отсутствия обратной совместимости, мы могли бы изменить наши протоколы и спецификации, чтобы исключить поле дополнения в Destination, Router Identity или обоих.
Это предложение имеет некоторое сходство с форматом зашифрованного leaseset “b33”, содержащим только ключ и поле типа.
Для поддержания некоторой совместимости, определенные уровни протокола могли бы “расширить” поле дополнения всеми нулями для представления другим уровням протокола.
Для Destinations мы могли бы также удалить поле типа шифрования в сертификате ключа, что позволит сэкономить два байта. Альтернативно, Destinations могли бы получить новый тип шифрования в сертификате ключа, указывающий на нулевой открытый ключ (и дополнение).
Если конвертация между старыми и новыми форматами не будет включена на каком-то уровне протокола, следующие спецификации, API, протоколы и приложения будут затронуты:
- Спецификация общих структур
- I2NP
- I2CP
- NTCP2
- SSU2
- Ratchet
- Streaming
- SAM
- Bittorrent
- Reseeding
- Файл закрытого ключа
- Java ядро и API маршрутизатора
- i2pd API
- Сторонние библиотеки SAM
- Встроенные и сторонние инструменты
- Несколько Java плагинов
- Пользовательские интерфейсы
- P2P приложения напр. MuWire, биткойн, монеро
- hosts.txt, addressbook и подписки
Если конвертация указана на каком-то уровне, список будет сокращен.
Затраты и выгоды этих изменений не ясны.
Конкретные предложения TBD:
PQ Ключи
Пост-квантовые (PQ) открытые ключи шифрования для любого предполагаемого алгоритма больше 256 байт. Это исключило бы любое дополнение и любую экономию от предложенных выше изменений для Router Identities.
В “гибридном” подходе PQ, как это делает SSL, PQ ключи будут только эфемерными, и не будут появляться в Router Identity.
PQ ключи подписи не жизнеспособны, и Destinations не содержат открытых ключей шифрования. Статические ключи для ratchet находятся в Lease Set, а не в Destination. так что мы можем исключить Destinations из дальнейшего обсуждения.
Таким образом, PQ влияет только на Router Infos, и только для статических (а не эфемерных) PQ ключей, не для гибридных PQ. Это было бы для нового типа шифрования и коснулось бы NTCP2, SSU2, и зашифрованные сообщения Database Lookup и ответы. Планируемые сроки для проектирования, разработки и развертывания этого были бы ??????????? Но это было бы после гибрида или ratchet ????????????
Для дальнейшего обсуждения см. this topic.
Вопросы
Может быть желательно проводить постепенное обновление ключей в сети, чтобы предоставить прикрытие для новых маршрутизаторов. “Обновление ключей” могло бы означать просто изменение дополнения, а не реальное изменение ключей.
Невозможно обновить существующие Destinations.
Следует ли идентифицировать Router Identities с дополнением в поле открытого ключа с другим типом шифрования в сертификате ключа? Это вызвало бы проблемы с совместимостью.
Миграция
Нет проблем обратной совместимости для замены ключа ElGamal на дополнение.
Обновление ключей, если будет реализовано, будет аналогично проводившемуся в трех предыдущих переходах идентичности маршрутизаторов: От DSA-SHA1 к подписям ECDSA, затем к подписям EdDSA, затем к шифрованию X25519.
С учетом проблем обратной совместимости и после отключения SSU, реализации могут полностью удалить код ElGamal. Примерно 14% маршрутизаторов в сети имеют тип шифрования ElGamal, включая многих floodfills.
Чертеж запроса на слияние для Java I2P находится в git.idk.i2p.