Постквантовые криптографические протоколы

Состояние

Обзор

Хотя исследования и конкурс подходящих постквантовых (PQ) криптографических алгоритмов ведутся уже десять лет, выбор стал ясен лишь недавно.

Мы начали изучать последствия PQ криптографии в 2022 году zzz.i2p .

Стандарты TLS добавили поддержку гибридного шифрования за последние два года, и теперь оно используется для значительной части зашифрованного трафика в интернете благодаря поддержке в Chrome и Firefox Cloudflare .

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

И Cloudflare , и NIST рекомендуют немедленно начать миграцию. См. также FAQ по постквантовой криптографии NSA за 2022 год NSA . I2P должен быть лидером в области безопасности и криптографии. Сейчас самое время реализовать рекомендуемые алгоритмы. Используя нашу гибкую систему типов шифрования и типов подписей, мы добавим типы для гибридной криптографии, а также для постквантовых и гибридных подписей.

Цели

• Выбрать алгоритмы, устойчивые к квантовым атакам
• Добавить только PQ и гибридные алгоритмы в протоколы I2P там, где это уместно
• Определить множественные варианты
• Выбрать лучшие варианты после реализации, тестирования, анализа и исследований
• Добавить поддержку постепенно и с обратной совместимостью

Не-цели

• Не изменять односторонние протоколы шифрования (Noise N)
• Не отказываться от SHA256, в ближайшем будущем не подвержен угрозе от PQ
• Не выбирать окончательные предпочтительные варианты на данный момент

Модель угроз

• Router’ы на OBEP или IBGW, возможно действующие сообща, сохраняющие garlic сообщения для последующей расшифровки (forward secrecy)
• Наблюдатели сети, сохраняющие транспортные сообщения для последующей расшифровки (forward secrecy)
• Участники сети, подделывающие подписи для RI, LS, streaming, датаграмм или других структур

Затронутые протоколы

Мы будем изменять следующие протоколы примерно в порядке разработки. Общее развертывание, вероятно, будет происходить с конца 2025 года до середины 2027 года. Подробности см. в разделе “Приоритеты и развертывание” ниже.

Дизайн

Мы будем поддерживать стандарты NIST FIPS 203 и 204 FIPS 203 FIPS 204 , которые основаны на CRYSTALS-Kyber и CRYSTALS-Dilithium (версии 3.1, 3 и более старые), но НЕ совместимы с ними.

Обмен ключами

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

Noise N не использует двусторонний обмен ключами и поэтому не подходит для гибридного шифрования.

Таким образом, мы будем поддерживать только гибридное шифрование для NTCP2, SSU2 и Ratchet. Мы определим три варианта ML-KEM согласно FIPS 203 , всего для 3 новых типов шифрования. Гибридные типы будут определены только в сочетании с X25519.

Новые типы шифрования:

Подписи

Мы будем поддерживать PQ и гибридные подписи в следующих структурах:

Таким образом, мы будем поддерживать как PQ-только, так и гибридные подписи. Мы определим три варианта ML-DSA как в FIPS 204 , три гибридных варианта с Ed25519 и три PQ-только варианта с предварительным хешированием только для SU3-файлов, итого 9 новых типов подписей. Гибридные типы будут определены только в сочетании с Ed25519. Мы будем использовать стандартный ML-DSA, НЕ варианты с предварительным хешированием (HashML-DSA), за исключением SU3-файлов.

Новые типы подписей:

Сертификаты X.509 и другие кодировки DER будут использовать композитные структуры и OID, определенные в черновике IETF .

Поскольку новые типы назначений и router identity не будут содержать заполнения, они не будут сжимаемыми. Размеры назначений и router identity, которые сжимаются gzip при передаче, увеличатся в 12-38 раз в зависимости от алгоритма.

Для Destinations новые типы подписей поддерживаются со всеми типами шифрования в leaseset. Установите тип шифрования в сертификате ключа на NONE (255).

Допустимые Комбинации

Для RouterIdentities тип шифрования ElGamal устарел. Новые типы подписей поддерживаются только с шифрованием X25519 (тип 4). Новые типы шифрования будут указаны в RouterAddresses. Тип шифрования в сертификате ключа продолжит быть типом 4.

Тестовые векторы для SHA3-256, SHAKE128 и SHAKE256 доступны на сайте NIST .

Требуется новая криптография

• ML-KEM (ранее CRYSTALS-Kyber) FIPS 203
• ML-DSA (ранее CRYSTALS-Dilithium) FIPS 204
• SHA3-128 (ранее Keccak-256) FIPS 202 Используется только для SHAKE128
• SHA3-256 (ранее Keccak-512) FIPS 202
• SHAKE128 и SHAKE256 (расширения XOF для SHA3-128 и SHA3-256) FIPS 202

Обратите внимание, что библиотека Java bouncycastle поддерживает все вышеперечисленное. Поддержка библиотеки C++ находится в OpenSSL 3.5 OpenSSL .

Мы не будем поддерживать FIPS 205 (Sphincs+), он намного медленнее и больше по размеру, чем ML-DSA. Мы не будем поддерживать готовящийся FIPS206 (Falcon), он еще не стандартизован. Мы не будем поддерживать NTRU или других кандидатов на постквантовую криптографию, которые не были стандартизованы NIST.

Альтернативы

Существует исследовательская статья по адаптации Wireguard (IK) для чистой PQ криптографии, но в этой статье остается несколько открытых вопросов. Позже этот подход был реализован как Rosenpass Rosenpass техническая документация для PQ Wireguard.

Rosenpass

Rosenpass использует рукопожатие типа Noise KK с предварительно разделёнными статическими ключами Classic McEliece 460896 (по 500 КБ каждый) и эфемерными ключами Kyber-512 (по сути MLKEM-512). Поскольку шифротексты Classic McEliece составляют всего 188 байт, а открытые ключи и шифротексты Kyber-512 имеют разумный размер, оба сообщения рукопожатия помещаются в стандартный UDP MTU. Выходной разделяемый ключ (osk) из постквантового рукопожатия KK используется в качестве входного предварительно разделённого ключа (psk) для стандартного рукопожатия Wireguard IK. Таким образом, всего происходит два полных рукопожатия: одно чисто постквантовое и одно чисто X25519.

Мы не можем использовать ничего из этого для замены наших XK и IK handshake, потому что:

В техническом документе содержится много полезной информации, и мы изучим её для получения идей и вдохновения. TODO.

• Мы не можем использовать KK, у Боба нет статического ключа Алисы
• Статические ключи размером 500КБ слишком большие
• Мы не хотим дополнительного обмена сообщениями

Обновите разделы и таблицы в документе общих структур /docs/specs/common-structures/ следующим образом:

Спецификация

Общие структуры

Новые типы публичных ключей:

PublicKey

Гибридные публичные ключи представляют собой ключи X25519. Публичные ключи KEM представляют собой эфемерные PQ ключи, отправляемые от Алисы к Бобу. Кодирование и порядок байтов определены в FIPS 203 .

Новые типы приватных ключей:

PrivateKey

Гибридные приватные ключи - это X25519 ключи. KEM приватные ключи предназначены только для Алисы. Кодирование KEM и порядок байтов определены в FIPS 203 .

SigningPublicKey

Гибридные открытые ключи для подписи представляют собой ключ Ed25519, за которым следует PQ ключ, как описано в черновике IETF . Кодирование и порядок байтов определены в FIPS 204 .

SigningPrivateKey

Гибридные закрытые ключи подписи представляют собой ключ Ed25519, за которым следует PQ ключ, как описано в черновике IETF . Кодировка и порядок байтов определены в FIPS 204 .

Подпись

Гибридные подписи представляют собой подпись Ed25519, за которой следует PQ подпись, как в IETF draft . Гибридные подписи проверяются путем проверки обеих подписей, и проверка считается неудачной, если любая из них не прошла. Кодирование и порядок байтов определены в FIPS 204 .

Сертификаты ключей

Гибридные открытые ключи для подписи представляют собой ключ Ed25519, за которым следует PQ ключ, как описано в черновике IETF . Кодирование и порядок байтов определены в FIPS 204 .

Для назначений с типами подписи Hybrid или PQ используйте NONE (тип 255) для типа шифрования, но криптографический ключ отсутствует, и вся основная секция размером 384 байта предназначена для ключа подписи.

Размеры назначений

Вот длины для новых типов Destination. Тип шифрования для всех - NONE (тип 255), и длина ключа шифрования считается равной 0. Вся 384-байтовая секция используется для первой части публичного ключа подписи. ПРИМЕЧАНИЕ: Это отличается от спецификации для типов подписей ECDSA_SHA512_P521 и RSA, где мы сохраняли 256-байтовый ключ ElGamal в destination, даже если он не использовался.

Без заполнения. Общая длина составляет 7 + общая длина ключа. Длина сертификата ключа составляет 4 + избыточная длина ключа.

Пример 1319-байтового потока байтов назначения для MLDSA44:

skey[0:383] 5 (932 » 8) (932 & 0xff) 00 12 00 255 skey[384:1311]

Размеры RouterIdent

Вот длины для новых типов Destination. Тип шифрования для всех — X25519 (тип 4). Вся 352-байтная секция после публичного ключа X25519 используется для первой части публичного ключа подписи. Без заполнения. Общая длина составляет 39 + общая длина ключа. Длина сертификата ключа составляет 4 + избыточная длина ключа.

Пример 1351-байтового потока байтов идентификации router для MLDSA44:

enckey[0:31] skey[0:351] 5 (960 » 8) (960 & 0xff) 00 12 00 4 skey[352:1311]

Паттерны рукопожатия

Рукопожатия используют шаблоны рукопожаний Noise Protocol .

Используется следующее соответствие букв:

• e = одноразовый эфемерный ключ
• s = статический ключ
• p = полезная нагрузка сообщения
• e1 = одноразовый эфемерный PQ ключ, отправленный от Alice к Bob
• ekem1 = шифротекст KEM, отправленный от Bob к Alice

Следующие модификации XK и IK для гибридной прямой секретности (hfs) указаны в спецификации Noise HFS spec , раздел 5:

XK:                       XKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, p               -> e, es, e1, p
  <- e, ee, p               <- e, ee, ekem1, p
  -> s, se                  -> s, se
  <- p                      <- p
  p ->                      p ->


  IK:                       IKhfs:
  <- s                      <- s
  ...                       ...
  -> e, es, s, ss, p       -> e, es, e1, s, ss, p
  <- tag, e, ee, se, p     <- tag, e, ee, ekem1, se, p
  <- p                     <- p
  p ->                     p ->

  e1 and ekem1 are encrypted. See pattern definitions below.
  NOTE: e1 and ekem1 are different sizes (unlike X25519)

Паттерн e1 определяется следующим образом, как указано в разделе 4 спецификации Noise HFS :

For Alice:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++
  MixHash(ciphertext)

  For Bob:

  // DecryptAndHash(ciphertext)
  encap_key = DECRYPT(k, n, ciphertext, ad)
  n++
  MixHash(ciphertext)

Шаблон ekem1 определен следующим образом, как указано в разделе 4 спецификации Noise HFS :

For Bob:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  MixKey(kem_shared_key)


  For Alice:

  // DecryptAndHash(ciphertext)
  kem_ciphertext = DECRYPT(k, n, ciphertext, ad)
  MixHash(ciphertext)

  // MixKey
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  MixKey(kem_shared_key)

Noise Handshake KDF

Проблемы

• Следует ли нам изменить хеш-функцию handshake? См. сравнение . SHA256 не уязвим к PQ, но если мы хотим обновить нашу хеш-функцию, сейчас самое время, пока мы меняем другие вещи. Текущее предложение IETF SSH IETF draft — использовать MLKEM768 с SHA256 и MLKEM1024 с SHA384. Это предложение включает обсуждение соображений безопасности.
• Следует ли нам прекратить отправку 0-RTT ratchet данных (кроме LS)?
• Следует ли нам переключить ratchet с IK на XK, если мы не отправляем 0-RTT данные?

Обзор

Этот раздел применяется как к протоколам IK, так и к XK.

Гибридное рукопожатие определено в спецификации Noise HFS . Первое сообщение от Alice к Bob содержит e1, ключ инкапсуляции, перед полезной нагрузкой сообщения. Это рассматривается как дополнительный статический ключ; вызовите EncryptAndHash() на нем (как Alice) или DecryptAndHash() (как Bob). Затем обработайте полезную нагрузку сообщения как обычно.

Второе сообщение от Боба к Алисе содержит ekem1, зашифрованный текст, перед полезной нагрузкой сообщения. Это рассматривается как дополнительный статический ключ; вызовите EncryptAndHash() для него (как Боб) или DecryptAndHash() (как Алиса). Затем вычислите kem_shared_key и вызовите MixKey(kem_shared_key). После этого обработайте полезную нагрузку сообщения как обычно.

Определённые операции ML-KEM

Мы определяем следующие функции, соответствующие криптографическим строительным блокам, используемым согласно определению в FIPS 203 .

(encap_key, decap_key) = PQ_KEYGEN()

Alice creates the encapsulation and decapsulation keys
The encapsulation key is sent in message 1.
encap_key and decap_key sizes vary based on ML-KEM variant.

(ciphertext, kem_shared_key) = ENCAPS(encap_key)

Bob calculates the ciphertext and shared key,
using the ciphertext received in message 1.
The ciphertext is sent in message 2.
ciphertext size varies based on ML-KEM variant.
The kem_shared_key is always 32 bytes.

kem_shared_key = DECAPS(ciphertext, decap_key)

Alice calculates the shared key,
using the ciphertext received in message 2.
The kem_shared_key is always 32 bytes.

Обратите внимание, что как encap_key, так и зашифрованный текст находятся внутри блоков ChaCha/Poly в сообщениях Noise handshake 1 и 2. Они будут расшифрованы как часть процесса handshake.

kem_shared_key смешивается с chaining key при помощи MixHash(). Подробности см. ниже.

Alice KDF для сообщения 1

Для XK: После шаблона сообщения ’es’ и перед полезной нагрузкой добавить:

ИЛИ

Для IK: После шаблона сообщения ’es’ и перед шаблоном сообщения ’s’, добавьте:

This is the "e1" message pattern:
  (encap_key, decap_key) = PQ_KEYGEN()

  // EncryptAndHash(encap_key)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, encap_key, ad)
  n++

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)


  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

Bob KDF для сообщения 1

Для XK: После шаблона сообщения ’es’ и перед полезной нагрузкой добавить:

ИЛИ

Для IK: После шаблона сообщения ’es’ и перед шаблоном сообщения ’s’, добавьте:

This is the "e1" message pattern:

  // DecryptAndHash(encap_key_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  encap_key = DECRYPT(k, n, encap_key_section, ad)
  n++

  // MixHash(encap_key_section)
  h = SHA256(h || encap_key_section)

  End of "e1" message pattern.

  NOTE: For the next section (payload for XK or static key for IK),
  the keydata and chain key remain the same,
  and n now equals 1 (instead of 0 for non-hybrid).

KDF Боба для Сообщения 2

Для XK: После шаблона сообщения ’ee’ и перед полезной нагрузкой добавьте:

ИЛИ

Для IK: После шаблона сообщения ’ee’ и перед шаблоном сообщения ‘se’, добавить:

This is the "ekem1" message pattern:

  (kem_ciphertext, kem_shared_key) = ENCAPS(encap_key)

  // EncryptAndHash(kem_ciphertext)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  ciphertext = ENCRYPT(k, n, kem_ciphertext, ad)

  // MixHash(ciphertext)
  h = SHA256(h || ciphertext)

  // MixKey(kem_shared_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

Alice KDF для сообщения 2

После шаблона сообщения ’ee’ (и перед шаблоном сообщения ‘ss’ для IK), добавить:

This is the "ekem1" message pattern:

  // DecryptAndHash(kem_ciphertext_section)
  // AEAD parameters
  k = keydata[32:63]
  n = 0
  ad = h
  kem_ciphertext = DECRYPT(k, n, kem_ciphertext_section, ad)

  // MixHash(kem_ciphertext_section)
  h = SHA256(h || kem_ciphertext_section)

  // MixKey(kem_shared_key)
  kem_shared_key = DECAPS(kem_ciphertext, decap_key)
  keydata = HKDF(chainKey, kem_shared_key, "", 64)
  chainKey = keydata[0:31]

  End of "ekem1" message pattern.

  // AEAD parameters for payload section
  ... as in standard SSU2 ...
  k = keydata[32:63]
  ...

KDF для Сообщения 3 (только XK)

неизменный

KDF для split()

неизменный

Храповик

Обновите спецификацию ECIES-Ratchet /docs/specs/ecies/ следующим образом:

Идентификаторы Noise

• “Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_IKhfselg2_25519+MLKEM1024_ChaChaPoly_SHA256”

1b) Новый формат сессии (с привязкой)

Изменения: Текущий ratchet содержал статический ключ в первой секции ChaCha и полезную нагрузку во второй секции. С ML-KEM теперь есть три секции. Первая секция содержит зашифрованный PQ публичный ключ. Вторая секция содержит статический ключ. Третья секция содержит полезную нагрузку.

Зашифрованный формат:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   New Session Ephemeral Public Key    |
  +             32 bytes                  +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           ML-KEM encap_key            +
  |       ChaCha20 encrypted data         |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for encap_key Section        +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +           X25519 Static Key           +
  |       ChaCha20 encrypted data         |
  +             32 bytes                  +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +    (MAC) for Static Key Section       +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Расшифрованный формат:

Payload Part 1:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM encap_key                +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X25519 Static Key               +
  |                                       |
  +      (32 bytes)                       +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Размеры:

1g) Формат ответа о новой сессии

Изменения: Текущий ratchet имеет пустую полезную нагрузку для первой секции ChaCha и полезную нагрузку во второй секции. С ML-KEM теперь есть три секции. Первая секция содержит зашифрованный PQ ciphertext. Вторая секция имеет пустую полезную нагрузку. Третья секция содержит полезную нагрузку.

Зашифрованный формат:

  +----+----+----+----+----+----+----+----+
  |       Session Tag   8 bytes           |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Ephemeral Public Key           +
  |                                       |
  +            32 bytes                   +
  |     Encoded with Elligator2           |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  | ChaCha20 encrypted ML-KEM ciphertext  |
  +      (see table below for length)     +
  ~                                       ~
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for ciphertext Section         +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +  (MAC) for key Section (no data)      +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       ChaCha20 encrypted data         |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Message Authentication Code |
  +         (MAC) for Payload Section     +
  |             16 bytes                  |
  +----+----+----+----+----+----+----+----+

Расшифрованный формат:

Payload Part 1:


  +----+----+----+----+----+----+----+----+
  |                                       |
  +       ML-KEM ciphertext               +
  |                                       |
  +      (see table below for length)     +
  |                                       |
  ~                                       ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Payload Part 2:

  empty

  Payload Part 3:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |                                       |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+

Размеры:

NTCP2

Обновите спецификацию NTCP2 /docs/specs/ntcp2/ следующим образом:

Идентификаторы Noise

• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”
• “Noise_XKhfsaesobfse+hs2+hs3_25519+MLKEM1024_ChaChaPoly_SHA256”

1) SessionRequest

Изменения: Текущий NTCP2 содержит только опции в секции ChaCha. С ML-KEM секция ChaCha также будет содержать зашифрованный PQ публичный ключ.

Чтобы PQ и не-PQ NTCP2 могли поддерживаться на одном адресе и порту router’а, мы используем старший бит значения X (X25519 эфемерный открытый ключ) для обозначения PQ-соединения. Этот бит всегда сброшен для не-PQ соединений.

Для Алисы, после того как сообщение зашифровано с помощью Noise, но до AES-обфускации X, установить X[31] |= 0x7f.

Для Боба, после AES де-обфускации X, проверить X[31] & 0x80. Если бит установлен, очистить его с помощью X[31] &= 0x7f и расшифровать через Noise как PQ соединение. Если бит не установлен, расшифровать через Noise как обычное не-PQ соединение.

Для PQ NTCP2, анонсируемого на другом адресе и порту router’а, это не требуется.

Для получения дополнительной информации см. раздел “Опубликованные адреса” ниже.

Исходное содержимое:

  +----+----+----+----+----+----+----+----+
  |        MS bit set to 1 and then       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted X         |
  +             (32 bytes)                +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly encrypted data (MLKEM)   |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~                                       ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  ~         padding (optional)            ~
  |     length defined in options block   |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Незашифрованные данные (тег аутентификации Poly1305 не показан):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Примечание: поле версии в блоке опций сообщения 1 должно быть установлено в 2, даже для PQ-соединений.

Размеры:

2) SessionCreated

Необработанное содержимое:

Исходное содержимое:

  +----+----+----+----+----+----+----+----+
  |                                       |
  +        obfuscated with RH_B           +
  |       AES-CBC-256 encrypted Y         |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (options)   |
  +         16 bytes                      +
  +   k defined in KDF for message 2      +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

  Same as current specification except add a second ChaChaPoly frame

Незашифрованные данные (тег аутентификации Poly1305 не показан):

  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |               options                 |
  +              (16 bytes)               +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     unencrypted authenticated         |
  +         padding (optional)            +
  |     length defined in options block   |
  ~               .   .   .               ~
  |                                       |
  +----+----+----+----+----+----+----+----+

Размеры:

3) SessionConfirmed

Неизменно

Функция вывода ключей (KDF) (для фазы данных)

Неизменно

Опубликованные адреса

Во всех случаях используйте имя транспорта NTCP2 как обычно.

Различные адреса/порты как не-PQ, или только PQ, без файрвола НЕ поддерживаются. Это не будет реализовано до тех пор, пока не будет отключен не-PQ NTCP2, что произойдет через несколько лет. Когда не-PQ будет отключен, могут поддерживаться несколько вариантов PQ, но только один на адрес. В адресе router публикуется v=[3|4|5] для указания MLKEM 512/768/1024. Alice не устанавливает MSB эфемерного ключа. Старые router будут проверять параметр v и пропускать этот адрес как неподдерживаемый.

Адреса за firewall (IP не публикуется): В адресе router’а публикуйте v=2 (как обычно). Нет необходимости публиковать параметр pq.

Alice может подключиться к PQ Bob, используя PQ вариант, который публикует Bob, независимо от того, рекламирует ли Alice поддержку pq в информации своего router или рекламирует ли она тот же вариант.

В текущей спецификации сообщения 1 и 2 определены как имеющие “разумное” количество заполнения, с рекомендуемым диапазоном 0-31 байт и без указанного максимума.

Максимальное заполнение

Java I2P реализует максимум 256 байт заполнения для не-PQ соединений, однако это не было задокументировано ранее.

Используйте определенный размер сообщения как максимальное заполнение, то есть максимальное заполнение удвоит размер сообщения следующим образом:

Обновите спецификацию SSU2 /docs/specs/ssu2/ следующим образом:

SSU2

Обратите внимание, что MLKEM-1024 НЕ поддерживается для SSU2, поскольку ключи слишком большие, чтобы поместиться в стандартную датаграмму размером 1500 байт.

Идентификаторы Noise

• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM512_ChaChaPoly_SHA256”
• “Noise_XKhfschaobfse+hs1+hs2+hs3_25519+MLKEM768_ChaChaPoly_SHA256”

Длинный заголовок составляет 32 байта. Он используется до создания сессии для сообщений Token Request, SessionRequest, SessionCreated и Retry. Он также используется для сообщений Peer Test и Hole Punch вне сессии.

Длинный заголовок

В следующих сообщениях установите поле ver (версия) в длинном заголовке в 3 или 4, чтобы указать MLKEM-512 или MLKEM-768.

В следующих сообщениях устанавливайте поле ver (версия) в длинном заголовке равным 2, как обычно, даже если поддерживается MLKEM-512 или MLKEM-768. Реализации также могут устанавливать значение 3 или 4, если другая сторона это поддерживает, но это не обязательно. Реализации должны принимать любое значение от 2 до 4.

• (0) Запрос сеанса
• (1) Сеанс создан
• (9) Повтор (примечание: Повтор с завершением может содержать любую версию 2-4)
• (10) Запрос токена
• (11) Пробивка отверстия (Hole Punch)

Обсуждение: Установка поля версии в значение 3 или 4 может быть не строго необходима для всех типов сообщений, но это способствует более раннему обнаружению сбоев для неподдерживаемых постквантовых соединений. Token Request и Retry (типы 9 и 10) должны иметь версии 3/4 для согласованности. Hole Punch сообщения (тип 11) могут не требовать такой обработки, но мы будем следовать тому же шаблону для единообразия. Peer Test сообщения (тип 7) находятся вне сессии и не указывают на намерение инициировать сессию.

• (7) Тест узла (сообщения вне сессии 5-7)

Перед шифрованием заголовка:

неизменный

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+

  Destination Connection ID :: 8 bytes, unsigned big endian integer

  Packet Number :: 4 bytes, unsigned big endian integer

  type :: The message type = 0, 1, 7, 9, 10, or 11

  ver :: The protocol version = 2, 3, or 4 for non-PQ, MLKEM512, MLKEM768

  id :: 1 byte, the network ID (currently 2, except for test networks)

  flag :: 1 byte, unused, set to 0 for future compatibility

  Source Connection ID :: 8 bytes, unsigned big endian integer

  Token :: 8 bytes, unsigned big endian integer

Короткий заголовок

неизменный

SessionRequest (Тип 0)

Изменение KDF для защиты от спуфинга: Для решения проблем, поднятых в Предложении 165 [Prop165]_, но с другим решением, мы модифицируем KDF для Session Request. Это касается только PQ-сессий. KDF для не-PQ сессий остается неизменным.

Исходное содержимое:

// End of KDF for initial chain key (unchanged)
  // Bob static key
  // MixHash(bpk)
  h = SHA256(h || bpk);

  // Start of KDF for session request
  // NEW for PQ only
  // bhash = Bob router hash (32 bytes)
  // MixHash(bhash)
  h = SHA256(h || bhash);

  // Rest of KDF for session request, unchanged, as in SSU2 spec
  // MixHash(header)
  h = SHA256(h || header)

  ...

Исходное содержимое:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key         +
  |    See Header Encryption KDF          |
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with Bob intro key n=0     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       X, ChaCha20 encrypted           +
  |       with Bob intro key n=0          |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (MLKEM)     |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaCha20 encrypted data (payload)   |
  +          (length varies)              +
  |  k defined in KDF for Session Request |
  +  n = 0                                +
  |  see KDF for associated data          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Незашифрованные данные (тег аутентификации Poly1305 не показан):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                   X                   |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM encap_key            |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |     see below for allowed blocks      |
  +----+----+----+----+----+----+----+----+

Размеры, не включая накладные расходы IP:

Минимальный MTU для MLKEM768_X25519: Около 1316 для IPv4 и 1336 для IPv6.

SessionCreated (Тип 1)

Исходное содержимое:

Исходное содержимое:

  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 0-15, ChaCha20     |
  +  encrypted with Bob intro key and     +
  | derived key, see Header Encryption KDF|
  +----+----+----+----+----+----+----+----+
  |  Long Header bytes 16-31, ChaCha20    |
  +  encrypted with derived key n=0       +
  |  See Header Encryption KDF            |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +       Y, ChaCha20 encrypted           +
  |       with derived key n=0            |
  +              (32 bytes)               +
  |       See Header Encryption KDF       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (MLKEM)     |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (before mixKey)                      |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 encrypted data (payload)   |
  ~  length varies                        ~
  +  k defined in KDF for Session Created +
  |  (after mixKey)                       |
  +  n = 0; see KDF for associated data   +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +        Poly1305 MAC (16 bytes)        +
  |                                       |
  +----+----+----+----+----+----+----+----+

Незашифрованные данные (тег аутентификации Poly1305 не показан):

  +----+----+----+----+----+----+----+----+
  |      Destination Connection ID        |
  +----+----+----+----+----+----+----+----+
  |   Packet Number   |type| ver| id |flag|
  +----+----+----+----+----+----+----+----+
  |        Source Connection ID           |
  +----+----+----+----+----+----+----+----+
  |                 Token                 |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |                  Y                    |
  +              (32 bytes)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |           ML-KEM Ciphertext           |
  +      (see table below for length)     +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     Noise payload (block data)        |
  +          (length varies)              +
  |      see below for allowed blocks     |
  +----+----+----+----+----+----+----+----+

Размеры, не включая накладные расходы IP:

Минимальный MTU для MLKEM768_X25519: Около 1316 для IPv4 и 1336 для IPv6.

SessionConfirmed (Тип 2)

неизменный

KDF для фазы данных

неизменный

Тестирование реле и узлов

Следующие блоки содержат поля версии. Они останутся версии 2 (для совместимости с не-PQ Bob) и не изменятся на версию 3/4 для PQ.

• Запрос ретрансляции
• Ответ ретрансляции
• Введение ретрансляции
• Тест пира

Во всех случаях используйте имя транспорта SSU2 как обычно. MLKEM-1024 не поддерживается.

Опубликованные адреса

Используйте тот же адрес/порт, что и для non-PQ, non-firewalled. Поддерживается один или оба варианта PQ. В адресе router публикуйте v=2 (как обычно) и новый параметр pq=[3|4|3,4] для указания MLKEM 512/768/оба. Старые router проигнорируют параметр pq и подключатся non-pq как обычно.

Различный адрес/порт как non-PQ, или PQ-only, non-firewalled НЕ поддерживается. Это не будет реализовано до тех пор, пока non-PQ SSU2 не будет отключен, что произойдет через несколько лет. Когда non-PQ будет отключен, поддерживается один или оба варианта PQ. В адресе router’а публикуйте v=[3|4|3,4] для указания MLKEM 512/768/оба варианта. Старые router’ы будут проверять параметр v и пропускать этот адрес как неподдерживаемый.

Адреса за файрволлом (IP не публикуется): В адресе router публикуйте v=2 (как обычно). Параметр pq ДОЛЖЕН быть опубликован в адресах за файрволлом для поддержки relay.

Алиса может подключиться к PQ Бобу, используя PQ вариант, который публикует Боб, независимо от того, рекламирует ли Алиса поддержку pq в своей информации router или рекламирует ли она тот же вариант.

В текущей спецификации сообщения 1 и 2 определены как имеющие “разумное” количество заполнения, с рекомендуемым диапазоном 0-31 байт и без указанного максимума.

MTU

Будьте осторожны, чтобы не превысить MTU при использовании MLKEM768. Минимальный MTU для SSU2 составляет 1280, что является размером сообщения 1 без заполнения. Не включайте заполнение в сообщение 1, если MTU Alice или Bob составляет 1280.

Стриминг

Для сообщений 1 и 2, MLKEM768 увеличил бы размеры пакетов сверх минимального MTU в 1280. Вероятно, просто не будем поддерживать его для этого соединения, если MTU слишком низкий.

SU3 файлы

Для сообщений 1 и 2 MLKEM1024 увеличит размеры пакетов сверх максимального MTU в 1500 байт. Это потребует фрагментации сообщений 1 и 2, что станет серьезным усложнением. Скорее всего, мы этого делать не будем.

Relay и Peer Test: См. выше

TODO: Существует ли более эффективный способ определения подписывания/верификации, чтобы избежать копирования подписи?

ЗАДАЧИ

Черновик IETF раздел 8.1 запрещает использование HashML-DSA в сертификатах X.509 и не назначает OID для HashML-DSA из-за сложностей реализации и снижения безопасности.

Другие спецификации

Для PQ-only подписей SU3 файлов используйте OID, определенные в черновике IETF для вариантов без предварительного хеширования для сертификатов. Мы не определяем гибридные подписи SU3 файлов, поскольку нам может потребоваться хешировать файлы дважды (хотя HashML-DSA и X2559 используют одну и ту же хеш-функцию SHA512). Кроме того, объединение двух ключей и подписей в сертификате X.509 было бы полностью нестандартным.

Обратите внимание, что мы запрещаем подписывание файлов SU3 с помощью Ed25519, и хотя мы определили подписывание Ed25519ph, мы никогда не согласовали для него OID и не использовали его.

• SAMv3
• Bittorrent
• Руководство для разработчиков
• Именование / адресная книга / jump-серверы
• Другая документация

Анализ накладных расходов

Обмен ключами

Обычные типы подписей не разрешены для файлов SU3; используйте варианты ph (prehash).

Обновить другие документы, которые дают рекомендации по размерам Destination, включая:

Подписи

Скорость:

Скорости согласно отчёту Cloudflare :

Обновить другие документы, которые дают рекомендации по размерам Destination, включая:

Анализ безопасности

Типичные размеры ключей, подписей, RIdent, Dest или увеличения размера (Ed25519 включён для справки) при условии типа шифрования X25519 для RI. Указано добавленное увеличение размера для Router Info, LeaseSet, отвечаемых датаграмм и каждого из двух пакетов потокового режима (SYN и SYN ACK). Текущие Destinations и Leasesets содержат повторяющееся заполнение и могут сжиматься при передаче. Новые типы не содержат заполнения и не будут сжиматься, что приведёт к значительно большему увеличению размера при передаче. См. раздел проектирования выше.

Рукопожатия

Скорости по данным Cloudflare :

Предварительные результаты тестов на Java:

Подписи

Категории безопасности NIST кратко изложены в презентации NIST на слайде 10. Предварительные критерии: Наша минимальная категория безопасности NIST должна быть 2 для гибридных протоколов и 3 для протоколов только с постквантовой криптографией.

Это все гибридные протоколы. Реализации должны предпочитать MLKEM768; MLKEM512 недостаточно безопасен.

Настройки типа

Категории безопасности NIST FIPS 203 :

Данное предложение определяет как гибридные, так и только PQ типы подписей. Гибридный MLDSA44 предпочтительнее чем только PQ MLDSA65. Размеры ключей и подписей для MLDSA65 и MLDSA87 вероятно слишком велики для нас, по крайней мере поначалу.

Категории безопасности NIST FIPS 204 :

Хотя мы определим и реализуем 3 криптографических и 9 типов подписей, мы планируем измерять производительность в процессе разработки и дополнительно анализировать влияние увеличенных размеров структур. Мы также продолжим исследования и мониторинг разработок в других проектах и протоколах.

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

Предварительные настройки следующие, могут быть изменены:

Шифрование: MLKEM768_X25519

Примечания по реализации

Поддержка библиотек

Подписи: MLDSA44_EdDSA_SHA512_Ed25519

Предварительные ограничения следующие, могут быть изменены:

Варианты подписи

Шифрование: MLKEM1024_X25519 не разрешено для SSU2

Подписи: MLDSA87 и гибридный вариант вероятно слишком большие; MLDSA65 и гибридный вариант могут быть слишком большими

Надежность

Библиотеки Bouncycastle, BoringSSL и WolfSSL теперь поддерживают MLKEM и MLDSA. Поддержка OpenSSL будет в их релизе 3.5 от 8 апреля 2025 года OpenSSL .

Размеры структур

Библиотека Noise от southernstorm.com, адаптированная для Java I2P, содержала предварительную поддержку гибридных рукопожатий, но мы удалили её как неиспользуемую; нам придётся добавить её обратно и обновить для соответствия спецификации Noise HFS .

NetDB

Мы будем использовать “защищенный” или рандомизированный вариант подписи, а не “детерминистический” вариант, как определено в FIPS 204 раздел 3.4. Это гарантирует, что каждая подпись будет отличаться, даже при подписи одних и тех же данных, и обеспечивает дополнительную защиту от атак по побочным каналам. Хотя FIPS 204 указывает, что “защищенный” вариант является вариантом по умолчанию, это может быть или не быть правдой в различных библиотеках. Разработчики должны убедиться, что для подписи используется “защищенный” вариант.

Ratchet

Проблемы

Мы используем обычный процесс подписи (называемый Pure ML-DSA Signature Generation), который кодирует сообщение внутренне как 0x00 || len(ctx) || ctx || message, где ctx — это некоторое опциональное значение размером 0x00..0xFF. Мы не используем никакого опционального контекста. len(ctx) == 0. Этот процесс определён в FIPS 204 Алгоритм 2 шаг 10 и Алгоритм 3 шаг 5. Обратите внимание, что некоторые опубликованные тестовые векторы могут требовать установки режима, в котором сообщение не кодируется.

Увеличение размера приведет к гораздо большей фрагментации tunnel для хранилищ netDb, рукопожатий потоковой передачи и других сообщений. Проверьте изменения производительности и надежности.

• Если сообщение 1 меньше 919 байт, это текущий ratchet протокол.
• Если сообщение 1 больше или равно 919 байт, это вероятно MLKEM512_X25519. Сначала попробуйте MLKEM512_X25519, и если это не сработает, попробуйте текущий ratchet протокол.

Найдите и проверьте любой код, который ограничивает размер в байтах router info и leaseSet.

Пересмотреть и возможно уменьшить максимальное количество LS/RI, хранящихся в ОЗУ или на диске, чтобы ограничить рост объема хранилища. Увеличить минимальные требования к пропускной способности для floodfill-узлов?

• X25519 + MLKEM512
• X25519 + MLKEM768
• X25519 + MLKEM1024

Автоматическая классификация/обнаружение множественных протоколов на одних и тех же туннелях должна быть возможна на основе проверки длины сообщения 1 (New Session Message). Используя MLKEM512_X25519 в качестве примера, длина сообщения 1 на 816 байт больше, чем в текущем ratchet протоколе, и минимальный размер сообщения 1 (с включением только полезной нагрузки DateTime) составляет 919 байт. Большинство размеров сообщения 1 в текущем ratchet имеют полезную нагрузку менее 816 байт, поэтому они могут быть классифицированы как не-гибридный ratchet. Крупные сообщения, вероятно, являются POST-запросами, которые встречаются редко.

• Более одного MLKEM
• ElG + один или более MLKEM
• X25519 + один или более MLKEM
• ElG + X25519 + один или более MLKEM

Итак, рекомендуемая стратегия:

Это должно позволить нам эффективно поддерживать стандартный ratchet и гибридный ratchet на одном и том же назначении, точно так же, как мы ранее поддерживали ElGamal и ratchet на одном назначении. Поэтому мы можем перейти на гибридный протокол MLKEM гораздо быстрее, чем если бы мы не могли поддерживать двойные протоколы для одного назначения, поскольку мы можем добавить поддержку MLKEM к существующим назначениям.

Обязательные поддерживаемые комбинации:

Следующие комбинации могут быть сложными и НЕ обязательны к поддержке, но могут поддерживаться в зависимости от реализации:

Общие туннели

Мы можем не пытаться поддерживать несколько алгоритмов MLKEM (например, MLKEM512_X25519 и MLKEM_768_X25519) на одном и том же назначении. Выберите только один; однако это зависит от того, выберем ли мы предпочтительный вариант MLKEM, чтобы HTTP клиентские туннели могли использовать один из них. Зависит от реализации.

Прямая секретность

Мы МОЖЕМ попытаться поддерживать три алгоритма (например X25519, MLKEM512_X25519 и MLKEM769_X25519) на одном и том же назначении. Классификация и стратегия повторных попыток могут быть слишком сложными. Конфигурация и пользовательский интерфейс конфигурации могут быть слишком сложными. Зависит от реализации.

NTCP2

Мы, вероятно, НЕ будем пытаться поддерживать алгоритмы ElGamal и гибридные алгоритмы на одном и том же назначении. ElGamal устарел, а ElGamal + гибридный алгоритм только (без X25519) не имеет особого смысла. Кроме того, сообщения New Session для ElGamal и гибридных алгоритмов оба имеют большой размер, поэтому стратегии классификации часто должны были бы пробовать оба варианта расшифровки, что было бы неэффективно. Зависит от реализации.

Размер новой сессии

Клиенты могут использовать одинаковые или разные статические ключи X25519 для протоколов X25519 и гибридного протокола на одних и тех же туннелях, в зависимости от реализации.

Спецификация ECIES позволяет включать Garlic Messages в полезную нагрузку New Session Message, что обеспечивает доставку начального streaming-пакета с нулевым RTT (0-RTT), обычно HTTP GET, вместе с leaseSet клиента. Однако полезная нагрузка New Session Message не обладает прямой секретностью. Поскольку данное предложение делает акцент на усиленной прямой секретности для ratchet, реализации могут или должны отложить включение streaming-полезной нагрузки или полного streaming-сообщения до первого Existing Session Message. Это произойдет за счет отказа от доставки 0-RTT. Стратегии также могут зависеть от типа трафика или типа tunnel, или от GET против POST, например. Зависит от реализации.

MLKEM, MLDSA или оба на одном и том же destination значительно увеличат размер сообщения New Session Message, как описано выше. Это может существенно снизить надежность доставки сообщений New Session Message через tunnel, где они должны быть фрагментированы на несколько сообщений tunnel размером 1024 байта. Успех доставки пропорционален экспоненциальному числу фрагментов. Реализации могут использовать различные стратегии для ограничения размера сообщения за счет доставки 0-RTT. Зависит от реализации.

Примечание: Коды типов предназначены только для внутреннего использования. Router останутся типа 4, а поддержка будет указана в адресах router.

SSU2

Мы устанавливаем MSB эфемерного ключа (key[31] & 0x80) в запросе сессии, чтобы указать, что это гибридное соединение. Это позволяет нам запускать как стандартный NTCP, так и гибридный NTCP на одном и том же порту. Поддерживался бы только один гибридный вариант, который рекламировался бы в адресе router. Например, v=2,3 или v=2,4 или v=2,5.

Как Bob, проверьте, если (X[31] & 0x80) != 0 после деобфускации. Если да, то это PQ соединение.

Примечание: Коды типов предназначены только для внутреннего использования. Router останутся типа 4, а поддержка будет указана в адресах router.

Совместимость router

Названия транспортов

Минимальная версия router, необходимая для NTCP2-PQ, будет определена позже.

Типы шифрования router

Мы используем поле версии в длинном заголовке и устанавливаем его в 3 для MLKEM512 и 4 для MLKEM768. v=2,3,4 в адресе будет достаточно.

Обфускация

Проверить и убедиться, что SSU2 может обрабатывать MLDSA-подписанный RI, фрагментированный на несколько пакетов (6-8?).

Маршрутизаторы типа 5/6/7

Примечание: Коды типов предназначены только для внутреннего использования. Router останутся типа 4, а поддержка будет указана в адресах router.

Routers типа 4

Во всех случаях используйте имена транспортов NTCP2 и SSU2 как обычно.

Типы подписей router

Рекомендации

У нас есть несколько альтернатив для рассмотрения:

Не рекомендуется. Используйте только новые транспорты, перечисленные выше, которые соответствуют типу router. Старые router не могут подключаться, строить tunnel через них или отправлять netDb сообщения. Потребуется несколько циклов релизов для отладки и обеспечения поддержки перед включением по умолчанию. Может продлить развертывание на год или более по сравнению с альтернативами ниже.

Типы шифрования LS

Router типа 12-17

Рекомендуется. Поскольку PQ не влияет на статический ключ X25519 или протоколы handshake N, мы можем оставить router как тип 4 и просто анонсировать новые транспорты. Старые router всё ещё смогут подключаться, строить tunnel через них или отправлять сообщения netDb.

MLKEM-768 рекомендуется для Ratchet, NTCP2 и SSU2, как лучший баланс безопасности и длины ключа.

Типы подписей назначения

Ключи LS типа 5-7

Старые router’ы проверяют RI и поэтому не могут подключаться, строить tunnel’ы через них или отправлять netDb сообщения. Потребуется несколько циклов релизов для отладки и обеспечения поддержки перед включением по умолчанию. Будут те же проблемы, что и при развертывании enc. типа 5/6/7; может продлить развертывание на год или более по сравнению с альтернативой развертывания enc. типа 4, указанной выше.

Не рекомендуется. Используйте только новые транспорты, перечисленные выше, которые соответствуют типу router. Старые router не могут подключаться, строить tunnel через них или отправлять netDb сообщения. Потребуется несколько циклов релизов для отладки и обеспечения поддержки перед включением по умолчанию. Может продлить развертывание на год или более по сравнению с альтернативами ниже.

Приоритеты и развертывание

Нет альтернатив.

Destinations могут поддерживать несколько типов ключей, но только путем пробной расшифровки сообщения 1 с каждым ключом. Накладные расходы можно снизить, ведя подсчет успешных расшифровок для каждого ключа и сначала пробуя наиболее используемый ключ. Java I2P использует эту стратегию для ElGamal+X25519 на одном и том же destination.

Роутеры проверяют подписи leaseSet и поэтому не могут подключиться или получить leaseSet для назначений типа 12-17. Потребуется несколько циклов релизов для отладки и обеспечения поддержки перед включением по умолчанию.

Альтернативы отсутствуют.

Наиболее ценными данными является сквозной трафик, зашифрованный с помощью ratchet. Для внешнего наблюдателя между хопами tunnel’а данные зашифрованы еще дважды — шифрованием tunnel’а и транспортным шифрованием. Для внешнего наблюдателя между OBEP и IBGW данные зашифрованы только еще раз транспортным шифрованием. Для участника OBEP или IBGW единственным шифрованием является ratchet. Однако, поскольку tunnel’ы однонаправленные, перехват обоих сообщений в ratchet handshake потребовал бы сговора router’ов, если только tunnel’ы не были построены с OBEP и IBGW на одном router’е.

Внедрение подписи также будет происходить на год или более позже внедрения шифрования, поскольку обратная совместимость невозможна.

Работа над поддержкой подписей MLDSA в I2P приостановлена до конца 2027 или 2028 года, ожидая результатов работы стандартных организаций по выбору алгоритмов, возможному уменьшению размеров ключей и/или подписей, а также продвижению их внедрения в индустрии. См. CABFORUM и PLANTS . Кроме того, внедрение MLDSA в индустрии будет стандартизировано форумом CA/Browser Forum и центрами сертификации (CA). Центрам сертификации сначала потребуется поддержка аппаратных модулей безопасности (HSM), которой на данный момент нет CA/Browser Forum . Мы ожидаем, что форум CA/Browser Forum будет определять решения по конкретным параметрам, включая вопрос поддержки или требования составных подписей IETF draft .

Миграция

Если мы не можем поддерживать старый и новый протоколы ratchet на одних и тех же туннелях, миграция будет намного сложнее.

Мы должны иметь возможность просто попробовать один-затем-другой, как мы делали с X25519, чтобы это было доказано.

Проблемы

• Выбор Noise Hash - остаться с SHA256 или обновиться? SHA256 должен быть хорош ещё 20-30 лет, не угрожает PQ, См. презентацию NIST и презентацию NCCOE . Если SHA256 сломан, у нас будут худшие проблемы (netdb).
• NTCP2 отдельный порт, отдельный адрес router
• SSU2 relay / peer test
• SSU2 поле версии
• SSU2 версия адреса router

Ссылки

• CABFORUM
• Choosing-Hash
• CLOUDFLARE
• COMMON
• COMPOSITE-SIGS
• ECIES
• FORUM
• FIPS202
• FIPS203
• FIPS204
• FIPS205
• MLDSA-OIDS
• NIST-PQ
• NIST-PQ-UPDATE
• NIST-PQ-END
• NIST-VECTORS
• Noise
• Noise-Hybrid
• NSA-PQ
• NTCP2
• OPENSSL
• Prop165
• PQ-WIREGUARD
• RFC-2104
• Rosenpass
• Rosenpass-Whitepaper
• SSH-HYBRID
• SSU2
• TLS-HYBRID