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

Статус

Обзор

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

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

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

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

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

Цели

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

Не цели

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

Модель угроз

• Router’ы на OBEP или IBGW, возможно сговаривающиеся, сохраняющие garlic сообщения для последующей расшифровки (прямая секретность)
• Наблюдатели сети, сохраняющие транспортные сообщения для последующей расшифровки (прямая секретность)
• Участники сети, подделывающие подписи для 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 и гибридные подписи в следующих структурах:

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

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

Накладные расходы будут существенными. Типичные размеры destination и router identity Ed25519 составляют 391 байт. Они увеличатся в 3,5-6,8 раза в зависимости от алгоритма. Подписи Ed25519 составляют 64 байта. Они увеличатся в 38-76 раз в зависимости от алгоритма. Типичные подписанные RouterInfo, leaseSet, датаграммы с возможностью ответа и подписанные streaming-сообщения составляют около 1КБ. Они увеличатся в 3-8 раз в зависимости от алгоритма.

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

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

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

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

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

• 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

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

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

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

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

Rosenpass

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

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

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

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

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

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

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

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

PublicKey

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

MLKEM*_CT ключи на самом деле не являются публичными ключами, они представляют собой “зашифрованный текст”, отправляемый от Боба к Алисе в рукопожатии Noise. Они перечислены здесь для полноты картины.

PrivateKey

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

SigningPublicKey

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

SigningPrivateKey

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

Подпись

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

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

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

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

Размеры Destination

Вот длины для новых типов 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]

Шаблоны рукопожатий

Handshake используют паттерны handshake Noise Protocol .

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

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

Следующие модификации XK и IK для гибридной прямой секретности (hfs) указаны в спецификации Noise HFS разделе 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 определяется следующим образом, как указано в спецификации Noise HFS , раздел 4:

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)

KDF рукопожатия Noise

Проблемы

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

Обзор

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

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

Второе сообщение, от Боба к Алисе, содержит 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, так и ciphertext зашифрованы внутри блоков ChaCha/Poly в сообщениях рукопожатия Noise 1 и 2. Они будут расшифрованы как часть процесса рукопожатия.

Параметр 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).

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).

Bob 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.

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.

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

неизменённый

KDF для split()

неизменный

Ratchet

Обновить спецификацию 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) Формат ответа New Session Reply

Изменения: Текущий 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 также будет содержать зашифрованный постквантовый публичный ключ.

Изменения: Текущий 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 frame (MLKEM)            |
  +      (see table below for length)     +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  ~   n = 0                               ~
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   ChaChaPoly frame (options)          |
  +         32 bytes                      +
  |   k defined in KDF for message 1      |
  +   n = 0                               +
  |   see KDF for associated data         |
  +----+----+----+----+----+----+----+----+
  |     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)               +
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (MLKEM)            |
  +   Encrypted and authenticated data    +
  -      (see table below for length)     -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaChaPoly frame (options)          |
  +   Encrypted and authenticated data    +
  -           32 bytes                    -
  +   k defined in KDF for message 2      +
  |   n = 0; see KDF for associated data  |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |     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. В адресе router опубликуйте v=2 (как обычно) и новый параметр pq=[3|4|5] для указания MLKEM 512/768/1024. Alice устанавливает старший бит эфемерного ключа (key[31] & 0x80) в запросе сессии, чтобы указать, что это гибридное соединение. См. выше. Старые router будут игнорировать параметр pq и подключаться не-PQ как обычно.

Различные адрес/порт как не-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 байт заполнения для non-PQ соединений, однако это ранее не было задокументировано.

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

SSU2

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

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

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

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

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

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

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

• (0) Запрос сессии
• (1) Сессия создана
• (9) Повторная попытка
• (10) Запрос токена
• (11) Пробивание отверстия

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

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

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

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

Изменение 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          |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +                                       +
  |   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)

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

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

  +----+----+----+----+----+----+----+----+
  |  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 data (MLKEM)               |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  n = 0; see KDF for associated data   |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |   ChaCha20 data (payload)             |
  +   Encrypted and authenticated data    +
  |  length varies                        |
  +  k defined in KDF for Session Created +
  |  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.

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

PQ-подписи: блоки Relay, блоки Peer Test и сообщения Peer Test содержат подписи. К сожалению, PQ-подписи превышают размер MTU. В настоящее время отсутствует механизм фрагментации блоков Relay или Peer Test или сообщений на несколько UDP-пакетов. Протокол должен быть расширен для поддержки фрагментации. Это будет сделано в отдельном предложении (TBD). До завершения этой работы Relay и Peer Test поддерживаться не будут.

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

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

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

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

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

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

MTU

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

Проблемы

Мы можем внутренне использовать поле version и применять 3 для MLKEM512 и 4 для MLKEM768.

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

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

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

Потоковая передача

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

Файлы SU3

ЗАДАЧИ

Черновик 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 и не использовали его.

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

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

Новый максимальный размер Destination будет составлять 2599 (3468 в base 64).

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

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

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

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

Увеличение размера (байт):

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

Подписи

Размер:

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

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

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

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

Рукопожатия

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

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

Подписи

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

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

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

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

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

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

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

Signatures: 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 .

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

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

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

Надёжность

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

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

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

NetDB

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

Ratchet

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

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

Поэтому рекомендуемая стратегия:

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

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

Требуемые поддерживаемые комбинации:

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

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

• Более одного MLKEM
• ElG + один или несколько MLKEM
• X25519 + один или несколько MLKEM
• ElG + X25519 + один или несколько MLKEM

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

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

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

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

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

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

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

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

NTCP2

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

Обфускация

Как Alice, для PQ соединения, перед обфускацией, установите X[31] |= 0x80. Это делает X недействительным открытым ключом X25519. После обфускации AES-CBC рандомизирует его. MSB для X будет случайным после обфускации.

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

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

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

SSU2

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

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

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

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

Имена транспортов

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

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

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

Роутеры типа 5/6/7

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

Роутеры типа 4

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

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

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

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

Router типов 12-17

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

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

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

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

Они могут присутствовать в LS со старыми ключами type 4 X25519. Старые router игнорируют неизвестные ключи.

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

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

Типы 12-17 получателей

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

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

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

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

Наиболее тревожная модель угроз PQ прямо сейчас — это сохранение трафика сегодня для расшифровки через много-много лет (прямая секретность). Гибридный подход защитил бы от этого.

Модель угроз PQ по взлому ключей аутентификации за разумный период времени (скажем, несколько месяцев) с последующим выдачей себя за другого при аутентификации или расшифровкой почти в реальном времени, находится гораздо дальше в будущем? И именно тогда нам потребуется мигрировать на статические ключи PQC.

Итак, самая ранняя модель угроз PQ - это OBEP/IBGW, сохраняющие трафик для последующей расшифровки. Нам следует сначала реализовать гибридный ratchet.

Ratchet имеет наивысший приоритет. Транспорты идут следующими. Подписи имеют самый низкий приоритет.

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

Миграция

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

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

Проблемы

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

Ссылки

• 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