Этот перевод был создан с помощью машинного обучения и может быть не на 100% точным. Просмотреть английскую версию

Спецификация низкоуровневой криптографии

Низкоуровневые детали криптографических алгоритмов, используемых в I2P

Updated: 2025-05 Accurate for: 0.9.66

Обзор

Примечание: Данный документ в основном устарел. Смотрите следующие документы для актуальных спецификаций: > - ECIES > - Encrypted LeaseSet > - NTCP2 > - Red25519 > - SSU2 > - Tunnel Creation (ECIES)

Эта страница описывает низкоуровневые детали криптографии в I2P.

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

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

Различные протоколы и структуры данных в I2P включают поля для указания типа подписи и/или типа шифрования. Эти поля вместе с определениями типов определяют длину ключей и подписей, а также криптографические примитивы, необходимые для их использования. Определения типов подписей и шифрования находятся в спецификации общих структур .

Исходные протоколы I2P NTCP, SSU и ElGamal/AES+SessionTags используют комбинацию асимметричного шифрования ElGamal и симметричного шифрования AES. Новые протоколы NTCP2 и ECIES-X25519-AEAD-Ratchet используют комбинацию обмена ключами X25519 и симметричного шифрования ChaCha20/Poly1305.

  • ECIES-X25519-AEAD-Ratchet заменил ElGamal/AES+SessionTags.
  • NTCP2 заменил NTCP.
  • SSU2 заменил SSU.
  • Создание tunnel с X25519 заменило создание tunnel с ElGamal.

Асимметричное шифрование

Оригинальный алгоритм асимметричного шифрования в I2P - это ElGamal. Более новый алгоритм, используемый в нескольких местах, - это ECIES X25519 DH обмен ключами.

Мы находимся в процессе миграции всего использования ElGamal на X25519.

NTCP (с ElGamal) был переведен на NTCP2 (с X25519). ElGamal/AES+SessionTag переводится на ECIES-X25519-AEAD-Ratchet.

X25519

Подробности использования X25519 см. в разделах NTCP2 и ECIES .

ElGamal

ElGamal используется в нескольких местах в I2P:

  • Для шифрования сообщений TunnelBuild между router’ами
  • Для сквозного шифрования (destination-to-destination) как часть ElGamal/AES+SessionTag с использованием ключа шифрования в LeaseSet
  • Для шифрования некоторых netDb stores и запросов, отправляемых floodfill router’ам как часть ElGamal/AES+SessionTag (destination-to-router или router-to-router).

Мы используем общие простые числа для 2048-битного шифрования и расшифровки ElGamal, как указано в IETF RFC-3526 . В настоящее время мы используем ElGamal только для шифрования IV и сессионного ключа в одном блоке, за которым следует полезная нагрузка, зашифрованная AES с использованием этого ключа и IV.

Незашифрованный ElGamal содержит:

+----+----+----+----+----+----+----+----+
|nonz|           H(data)                |
+----+                                  +
|                                       |
+                                       +
|                                       |
+                                       +
|                                       |
+    +----+----+----+----+----+----+----+
|    |  data...
+----+----+----+-//

H(data) является SHA256 от данных, которые зашифрованы в блоке ElGamal, и ему предшествует случайный ненулевой байт. Этот байт действительно случаен начиная с версии 0.9.28; до этого он всегда был 0xFF. Возможно, в будущем он может использоваться для флагов. Данные, зашифрованные в блоке, могут быть длиной до 222 байт. Поскольку зашифрованные данные могут содержать значительное количество нулей, если открытый текст меньше 222 байт, рекомендуется, чтобы верхние уровни дополняли открытый текст до 222 байт случайными данными. Общая длина: обычно 255 байт.

Зашифрованный ElGamal содержит:

+----+----+----+----+----+----+----+----+
|  zero padding...       |              |
+----+----+----+-//-+----+              +
|                                       |
+                                       +
|       ElG encrypted part 1            |
~                                       ~
|                                       |
+    +----+----+----+----+----+----+----+
|    |   zero padding...      |         |
+----+----+----+----+-//-+----+         +
|                                       |
+                                       +
|       ElG encrypted part 2            |
~                                       ~
|                                       |
+         +----+----+----+----+----+----+
|         +
+----+----+

Каждая зашифрованная часть дополняется нулями до размера ровно 257 байт. Общая длина: 514 байт. При типичном использовании верхние уровни дополняют незашифрованные данные до 222 байт, что приводит к незашифрованному блоку размером 255 байт. Это кодируется как две зашифрованные части по 256 байт каждая, и перед каждой частью на этом уровне добавляется один байт нулевого заполнения.

См. код ElGamal ElGamalEngine .

Общий простой модуль является простым числом Oakley для 2048-битных ключей RFC-3526-S3 :

2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }

или как шестнадцатеричное значение:

FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF

Используя 2 в качестве генератора.

Короткая экспонента

Хотя стандартный размер экспоненты составляет 2048 бит (256 байт) и I2P PrivateKey занимает полные 256 байт, в некоторых случаях мы используем короткий размер экспоненты 226 бит (28,25 байта). Это должно быть безопасно для использования с простыми числами Oakley [vanOorschot1996] [BENCHMARKS].

Кроме того, [Koshiba2004], по-видимому, поддерживает это, согласно данной ветке sci.crypt [SCI.CRYPT]. Остальная часть PrivateKey дополняется нулями.

До выпуска 0.9.8 все router использовали короткую экспоненту. Начиная с выпуска 0.9.8, 64-битные x86 router используют полную 2048-битную экспоненту. Теперь все router используют полную экспоненту, за исключением небольшого количества router на очень медленном оборудовании, которые продолжают использовать короткую экспоненту из-за опасений относительно нагрузки на процессор. Переход на более длинную экспоненту для этих платформ является темой для дальнейшего изучения.

Устаревание

Уязвимость сети к атаке ElGamal и влияние перехода к большей битовой длине должны быть изучены. Может быть довольно сложно сделать любые изменения совместимыми с предыдущими версиями.

Симметричное шифрование

Оригинальный алгоритм симметричного шифрования в I2P — это AES. Новый алгоритм, используемый в нескольких местах, — это Authenticated Encryption with Associated Data (AEAD) ChaCha20/Poly1305.

Мы находимся в процессе миграции всего использования AES на ChaCha20/Poly1305.

NTCP (с AES) был мигрирован в NTCP2 (с ChaCha20/Poly1305). ElGamal/AES+SessionTag мигрируется в ECIES-X25519-AEAD-Ratchet.

ChaCha20/Poly1305

Подробности использования ChaCha20/Poly1305 см. в NTCP2 и ECIES .

AES

AES используется для симметричного шифрования в нескольких случаях:

  • Для шифрования SSU транспорта (см. раздел “Транспорты”) после обмена DH ключами
  • Для сквозного шифрования (destination-to-destination) как части ElGamal/AES+SessionTag
  • Для шифрования некоторых netDb хранилищ и запросов, отправляемых floodfill router’ам как части ElGamal/AES+SessionTag (destination-to-router или router-to-router).
  • Для шифрования периодических тестовых сообщений tunnel’ей, отправляемых router’ом самому себе через собственные tunnel’ы.

Мы используем AES с 256-битными ключами и 128-битными блоками в режиме CBC. Используемое заполнение указано в IETF RFC-2313 (PKCS#5 1.5, раздел 8.1 (для типа блока 02)). В данном случае заполнение состоит из псевдослучайно сгенерированных октетов для соответствия 16-байтным блокам. В частности, смотрите код CBC CryptixAESEngine и реализацию Cryptix AES CryptixRijndael_Algorithm , а также заполнение, находящееся в функции ElGamalAESEngine.getPadding ElGamalAESEngine .

Устаревание

Уязвимость сети к AES-атакам и влияние перехода на большую длину ключа подлежат изучению. Может быть довольно сложно сделать любое изменение обратно совместимым.

Подписи

Множество алгоритмов подписи с различной длиной ключей и подписей определяются типами подписей. Добавление новых типов подписей относительно простая задача.

EdDSA-SHA512-Ed25519 является текущим алгоритмом подписи по умолчанию. DSA, который был исходным алгоритмом до того, как мы добавили поддержку типов подписей, все еще используется в сети.

DSA

Подписи создаются и проверяются с помощью 1024-битного DSA (L=1024, N=160), как реализовано в DSAEngine . DSA был выбран потому, что он работает значительно быстрее для подписей, чем ElGamal.

SEED

160 бит:

86108236b8526e296e923a4015b4282845b572cc

Счётчик

33

DSA простое число (p)

1024 бит:

9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0
A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23
7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F
F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C
E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3
B6051F5B 22CC1C93

Частное DSA (q)

A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7

Генератор DSA (g)

1024 бит:

0C1F4D27 D40093B4 29E962D7 223824E0 BBC47E7C 832A3923
6FC683AF 84889581 075FF908 2ED32353 D4374D73 01CDA1D2
3C431F46 98599DDA 02451824 FF369752 593647CC 3DDC197D
E985E43D 136CDCFC 6BD5409C D2F45082 1142A5E6 F8EB1C3A
B5D0484B 8129FCF1 7BCE4F7F 33321C3C B3DBB14A 905E7B2B
3E93BE47 08CBCC82

SigningPublicKey составляет 1024 бита. SigningPrivateKey составляет 160 бит.

Устаревание

NIST-800-57 рекомендует минимум (L=2048, N=224) для использования после 2010 года. Это может быть частично смягчено “криптопериодом” или сроком жизни данного ключа.

Простое число было выбрано в 2003 году, и человек, который его выбрал (TheCrypto), в настоящее время больше не является разработчиком I2P. Поэтому мы не знаем, является ли выбранное простое число “сильным простым числом”. Если для будущих целей будет выбрано большее простое число, оно должно быть сильным простым числом, и мы задокументируем процесс его построения.

Новые алгоритмы подписи

Начиная с версии 0.9.12, router поддерживает дополнительные алгоритмы подписи, которые более безопасны, чем 1024-битный DSA. Первое использование было для Destinations; поддержка Router Identities была добавлена в версии 0.9.16. Существующие Destinations нельзя перенести со старых подписей на новые; однако есть поддержка одного tunnel с несколькими Destinations, и это предоставляет способ перехода на новые типы подписей. Тип подписи кодируется в Destination и Router Identity, так что новые алгоритмы подписи или кривые могут быть добавлены в любое время.

В настоящее время поддерживаются следующие типы подписей:

  • DSA-SHA1
  • ECDSA-SHA256-P256
  • ECDSA-SHA384-P384 (не широко используется)
  • ECDSA-SHA512-P521 (не широко используется)
  • EdDSA-SHA512-Ed25519 (по умолчанию начиная с релиза 0.9.15)
  • RedDSA-SHA512-Ed25519 (начиная с релиза 0.9.39)

Дополнительные типы подписей используются только на уровне приложений, в первую очередь для подписи и проверки файлов su3. Эти типы подписей следующие:

  • RSA-SHA256-2048 (не широко используется)
  • RSA-SHA384-3072 (не широко используется)
  • RSA-SHA512-4096
  • EdDSA-SHA512-Ed25519ph (начиная с релиза 0.9.25; не широко используется)

ECDSA

ECDSA использует стандартные кривые NIST и стандартные хеши SHA-2.

Мы перевели новые назначения на ECDSA-SHA256-P256 в период выпусков 0.9.16 - 0.9.19. Поддержка для Router Identities доступна с версии 0.9.16, а миграция существующих router’ов произошла в 2015 году.

RSA

Стандартный RSA PKCS#1 v1.5 (RFC 2313) с публичной экспонентой F4 = 65537.

RSA теперь используется для подписи всего доверенного контента, передаваемого вне сети, включая обновления router’ов, reseeding, плагины и новости. Подписи встроены в формат “su3” [UPDATES]. Рекомендуются и используются всеми известными подписантами 4096-битные ключи. RSA не используется и не планируется к использованию в каких-либо сетевых Destinations или Router Identities.

EdDSA 25519

Стандартный EdDSA с использованием кривой 25519 и стандартных 512-битных хэшей SHA-2.

Поддерживается с версии 0.9.15.

Destinations и Router Identities были перенесены в конце 2015 года.

RedDSA 25519

Стандартный EdDSA с использованием кривой 25519 и стандартных 512-битных хэшей SHA-2, но с другими приватными ключами и незначительными изменениями в подписании. Для зашифрованных leaseSet. Подробности см. в EncryptedLeaseSet и Red25519 .

Поддерживается начиная с версии 0.9.39.

Хеши

Хеши используются в алгоритмах подписи и в качестве ключей в DHT сети.

Старые алгоритмы подписи используют SHA1 и SHA256. Новые алгоритмы подписи используют SHA512. DHT использует SHA256.

SHA256

DHT хеши в I2P являются стандартными SHA256.

Устаревание

Уязвимость сети к атаке на SHA-256 и влияние перехода к более длинному хешу подлежат изучению. Может быть довольно сложно сделать любые изменения обратно совместимыми.

Транспорты

На самом низком уровне протокола межмаршрутизаторная связь точка-точка защищена безопасностью транспортного уровня.

NTCP2 соединения используют X25519 Diffie-Hellman и аутентифицированное шифрование ChaCha20/Poly1305.

Транспорты SSU и устаревший NTCP используют 256-байтный (2048-битный) обмен ключами Diffie-Hellman, используя те же общие простое число и генератор, которые указаны выше для ElGamal, с последующим симметричным шифрованием AES, как описано выше.

SSU планируется мигрировать на SSU2 (с X25519 и ChaCha20/Poly1305).

Все транспорты обеспечивают совершенную прямую секретность PFS на транспортных соединениях.

NTCP2 соединения

NTCP2 соединения используют X25519 Diffie-Hellman и ChaCha20/Poly1305 аутентифицированное шифрование, а также протокольный фреймворк Noise Noise .

Подробности и ссылки смотрите в спецификации NTCP2 NTCP2 .

UDP соединения

SSU (UDP транспорт) шифрует каждый пакет с помощью AES256/CBC с явным IV и MAC (HMAC-MD5-128) после согласования эфемерного сессионного ключа через 2048-битный обмен Diffie-Hellman, аутентификации station-to-station с DSA ключом другого router’а, плюс каждое сетевое сообщение имеет свой собственный хеш для локальной проверки целостности.

См. спецификацию SSU для подробностей.

ПРЕДУПРЕЖДЕНИЕ - HMAC-MD5-128, используемый в SSU протоколе I2P, по-видимому, не соответствует стандарту. Видимо, ранняя версия SSU использовала HMAC-SHA256, а затем был произведён переход на MD5-128 по соображениям производительности, но размер буфера в 32 байта остался неизменным. Подробности см. в HMACGenerator.java и в заметках о состоянии от 2005-07-05.

NTCP соединения

NTCP больше не используется, он был заменен на NTCP2.

NTCP соединения согласовывались с использованием 2048-битной реализации Diffie-Hellman, применяя идентичность router для выполнения соглашения станция-к-станции, с последующими зашифрованными полями, специфичными для протокола, при этом все последующие данные шифровались с помощью AES (как указано выше). Основная причина для выполнения DH согласования вместо использования ElGamalAES+SessionTag заключается в том, что это обеспечивает ‘(совершенную) прямую секретность’ PFS , в то время как ElGamalAES+SessionTag этого не обеспечивает.

Ссылки

Was this page helpful?