RFC 10042 Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH

Опубликовано 31.08.2026 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                     P. Kampanakis
Request for Comments: 10042                                          AWS
Category: Informational                                       D. Stebila
ISSN: 2070-1721                                   University of Waterloo
                                                               T. Hansen
                                                                     AWS
                                                             August 2026

Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH

Гибридный обмен ключами PQ/T на основе ML-KEM для применения в SSH

PDF

Аннотация

Этот документ задаёт методы гибридного обмена ключами PQ/T (Post-Quantum Traditional) на основе стандарта квантово-стойкого (quantum-resistant) механизма инкапсуляции ключей на основе модульных решёток (Module-Lattice-Based Key-Encapsulation Mechanism или ML-KEM) и традиционной схемы Диффи-Хеллмана с эллиптической кривой (Elliptic-Curve Diffie-Hellman или ECDH). Методы предназначены для использовании в протоколе транспортного уровня Secure Shell (SSH).

Статус документа

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все документы, одобренные IESG, претендуют на статус стандартов (см. раздел 2 в RFC 7841).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc10042.

Авторские права

Авторские права (Copyright (c) 2026) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с пересмотренной лицензией BSD (Revised BSD License), как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).

1. Введение

В протоколе Secure Shell (SSH) [RFC4251] ключи организуются с использованием методов обмена ключами на основе схем Диффи-Хеллмана с эллиптическими кривыми (Elliptic Curve Diffie-Hellman или ECDH), заданных в [RFC5656] и [RFC8731]. Криптографическая безопасность этих обменов полагается на вычислительную невыполнимость задачи дискретного логарифмирования в некоторых случаях. Если станут доступны достаточно большие квантовые компьютеры, способные выполнить требуемые расчёты, это поставит под угрозу безопасность текущих методов обмена ключами и аутентификации SSH. Хотя большие квантовые компьютеры пока недоступны, злоумышленник может записать зашифрованное сообщение, переданное между клиентом и сервером в сессии SSH, и расшифровать его после появления достаточно больших квантовых компьютеров. Этот тип атак известен как «собрать сейчас, расшифровать позже» (harvest now, decrypt later) [RFC9958].

Документ решает эту проблему путём расширения обмена ключами протокола транспортного уровня SSH (раздел 7 в [RFC4253]) гибридными методами обмена ключами PQ/T [RFC9794]. Это соответствует рекомендациям по переходу, представленным в параграфе 4.3 [OAM-CONS]. Безопасность, обеспечиваемая каждой схемой обмена ключами в гибриде PQ/T, не зависит от других схем. Это означает, что метод гибридного обмена ключами PQ/T останется безопасным в той же мере, как и сама схема, применяемая как часть обмена. В работах [PQ-PROOF] и [PQ-PROOF2] приведены доказательства безопасности гибридных схем обмена ключами PQ/T.

В контексте [NIST_PQ] алгоритмы обмена ключами называются механизмами инкапсуляции ключей (Key-Encapsulation Mechanism или KEM) и состоят из трёх алгоритмов.

KeyGen() -> (pk, sk)

Вероятностный алгоритм генерации ключей, дающий на выходе открытый (pk) и секретный (sk) ключ.

Encaps(pk) -> (ct, ss)

Вероятностный алгоритм инкапсуляции, принимающий открытый ключ pk и выдающий шифротекст ct и общий секрет ss.

Decaps(sk, ct) -> ss

Алгоритм декапсуляции, принимающий секретный ключ sk и шифротекст ct и дающий общий секрет ss, а в некоторых случаях — различимое значение ошибки.

Основным свойством безопасности KEM является неразличимость при адаптивных атаках по выбранному шифротексту (indistinguishability under adaptive chosen ciphertext attack или IND-CCA2), означающая, что общим секретам следует быть неотличимыми от случайных строк даже с учётом возможности декапсуляции произвольных шифротекстов. IND-CCA2 соответствует защите от активных злоумышленников, а пару из открытого и секретного ключа можно считать долгосрочной и применять неоднократно. Более слабой в части обеспечения безопасности является неразличимость при атаках с выбранными открытыми данными (indistinguishability under chosen plaintext attack или IND-CPA), означающая, что значениям общих секретов следует быть неотличимыми от случайных строк для данной копии открытого ключа. IND-CPA примерно соответствует защите от пассивных атак и иногда соответствует обмену одноразовыми ключами.

В качестве пост-квантового KEM в этом документе применяется основанный на модульной решётке механизм инкапсуляции ключей (Module-Lattice-Based Key-Encapsulation Mechanism или ML-KEM). Механизм ML-KEM был стандартизован в 2024 г. [FIPS203] с тремя вариантами параметров — ML-KEM-512, ML-KEM-768 и ML-KEM-1024. Абстракция обмена сообщениями в гибридном методе PQ/T, вывод ключей и ввод данных для расчёта хэш-значения SSH H соответствуют заданным в [RFC9941], где применяется другой квантово-стойкий механизм KEM.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Гибридный обмен ключами PQ/T

2.1. Абстракция гибридного обмена ключами PQ/T

В этом параграфе задана абстрактная структура гибридного метода обмена ключами PQ/T, который должен включать две схемы обмена ключами. Типы данных byte и string в документе интерпретируются в соответствии с [RFC4251]. В гибридном обмене ключами PQ/T вместо SSH_MSG_KEXDH_INIT [RFC4253] или SSH_MSG_KEX_ECDH_INIT [RFC5656] клиент передаёт

          byte     SSH_MSG_KEX_HYBRID_INIT
          string   C_INIT

где C_INIT — конкатенация C_PK2 и C_PK1 (C_INIT = C_PK2 || C_PK1, || указывает конкатенацию). C_PK1 и C_PK2 представляют эфемерные открытые ключи для каждого обмена, применяемого в гибриде PQ/T. Обычно C_PK1 представляет традиционный/классический открытый ключ (например, ECDH), а C_PK2 представляет вывод pk соответствующего пост-квантового метода KEM KeyGen у клиента.

Вместо SSH_MSG_KEXDH_REPLY [RFC4253] или SSH_MSG_KEX_ECDH_REPLY [RFC5656] сервер передаёт

          byte     SSH_MSG_KEX_HYBRID_REPLY
          string   K_S, открытый ключ серверного хоста
          string   S_REPLY
          string   подпись хэш-значения обмена

где S_REPLY — конкатенация S_CT2 и S_PK1 (S_REPLY = S_CT2 || S_PK1). Обычно S_PK1 представляет эфемерный (EC)DH открытый ключ сервера, а S_CT2 — шифротекст ct, полученный из соответствующего алгоритма KEM Encaps на стороне сервера, который инкапсулирует секрет с открытым ключом клиента C_PK2. Перед созданием S_CT2 сервер должен проверить совпадение размера C_INIT с суммой ожидаемых размеров всех открытых ключей в согласованном методе (C_PK1 и C_PK2) для предотвращения атак с увеличением размеров ключей. Сервер должен также проверить ключ инкапсуляции в соответствии с параграфом 7.2 в [FIPS203]. Если любая из проверок не проходит, сервер3 должен прервать соединение, передав сообщение SSH_MSG_DISCONNECT с SSH_DISCONNECT_KEY_EXCHANGE_FAILED в качестве причины.

C_PK1, S_PK1, C_PK2 и S_CT2 служат для организации общих секретов K_CL и K_PQ. K_CL выводится при классическом обмене ECDH с использованием C_PK1 и S_PK1, а K_PQ — пост-квантовый общий секрет, декапсулированный из S_CT2. Перед декапсуляцией клиент должен проверить совпадение размера S_REPLY с суммой ожидаемых размеров традиционного открытого ключа S_PK1 и шифротекста ML-KEM S_CT2 в согласованном методе для предотвращения атак с увеличением размеров ключей. Клиент должен прервать соединение, передав сообщение SSH_MSG_DISCONNECT с причиной SSH_DISCONNECT_KEY_EXCHANGE_FAILED в случае любого отказа при проверке или декапсуляции. K_CL и K_PQ совместно применяются для создания общего секрета, как указано в параграфе 2.4.

Для всех методов клиент и сервер должны обрабатывать открытые ключи ECDH и X25519 (C_PK1 и S_PK1), как указано в разделе 4 [RFC5656] и разделе 3 [RFC8731], соответственно, включая проверку пригодности и размера с передачей разрывающего соединение SSH сообщения в случае отказа.

2.2. Номера сообщений гибридного обмена ключами PQ/T

Номера сообщений 30-49 выделены для методов обмена ключами в соответствии с [RFC4250]. Эти номера могут быть переопределены любым методом обмена ключами [RFC4253] без прохождения процесса регистрации в IANA. Данный документ задаёт два номера сообщений обмена ключами, указанных ниже.

         #define SSH_MSG_KEX_HYBRID_INIT               30
         #define SSH_MSG_KEX_HYBRID_REPLY              31

2.3. Имена методов гибридного обмена ключами PQ/T

Этот документ задаёт имена методов гибридного обмена ключами PQ/T для использования в SSH_MSG_KEXINIT [RFC4253]:

  • mlkem768nistp256-sha256;

  • mlkem1024nistp384-sha384;

  • mlkem768x25519-sha256.

Эти методы реализуют абстракцию гибридного обмена ключами PQ/T из параграфа 2.1.

2.3.1. mlkem768nistp256-sha256

В mlkem768nistp256-sha256 традиционные открытые ключи клиента и сервера (C_PK1 и S_PK1) относятся к кривой NIST P-256 [NIST-SP800-186]. Открытые и секретные ключи генерируются в соответствии с этим документом. Открытые ключи заданы как строки октетов для NIST P-256 в соответствии с [RFC5656] и может применяться сжатие точек. Общий секрет K_CL создаётся из полученных при обмене открытых ключей C_PK1 и S_PK1, как указано в [RFC5656] (метод согласования ключей ecdh-sha2-nistp256).

Пост-квантовые значения C_PK2 и S_CT2 представляют открытый ключ ML-KEM-768 и шифротекст от клиента и сервера, соответственно, кодируемые как строки октетов. Общий секрет K_PQ декапсулируется из шифротекста S_CT2 с использованием секретного ключа пост-квантового KEM, как указано в [FIPS203].

Хэш-функцией HASH, применяемой при обмене ключами [RFC4253], является SHA-256 [NIST-SHA2] [RFC6234].

2.3.2. mlkem1024nistp384-sha384

В mlkem768nistp384-sha384 традиционные открытые ключи клиента и сервера (C_PK1 и S_PK1) относятся к кривой NIST P-384 [NIST-SP800-186]. Открытые и секретные ключи генерируются в соответствии с этим документом. Открытые ключи заданы как строки октетов для NIST P-384 в соответствии с [RFC5656] и может применяться сжатие точек. Общий секрет K_CL создаётся из полученных при обмене открытых ключей C_PK1 и S_PK1, как указано в [RFC5656] (метод согласования ключей ecdh-sha2-nistp384).

Пост-квантовые значения C_PK2 и S_CT2 представляют открытый ключ ML-KEM-1024 и шифротекст от клиента и сервера, соответственно, кодируемые как строки октетов. Общий секрет K_PQ декапсулируется из шифротекста S_CT2 с использованием секретного ключа пост-квантового KEM, как указано в [FIPS203].

Хэш-функцией HASH, применяемой при обмене ключами [RFC4253], является SHA-384 [NIST-SHA2] [RFC6234].

2.3.3. mlkem768x25519-sha256

В mlkem768x25519-sha256 традиционные открытые ключи клиента и сервера (C_PK1 и S_PK1) относятся к кривой Curve25519 [RFC7748]. Открытые и секретные ключи генерируются в соответствии с этим документом. Открытые ключи заданы как строки из 32 октетов в соответствии с [RFC8731]. Общий секрет K_CL создаётся из полученных при обмене открытых ключей C_PK1 и S_PK1, как указано в [RFC8731] (метод согласования ключей curve25519-sha256).

Пост-квантовые значения C_PK2 и S_CT2 представляют открытый ключ ML-KEM-768 и шифротекст от клиента и сервера, соответственно, кодируемые как строки октетов. Общий секрет K_PQ декапсулируется из шифротекста S_CT2 с использованием секретного ключа пост-квантового KEM, как указано в [FIPS203].

Хэш-функцией HASH, применяемой при обмене ключами [RFC4253], является SHA-256 [NIST-SHA2] [RFC6234].

2.4. Общий секрет K

Гибридный обмен ключами PQ/T организует K_CL и K_PQ из обменов ключами ECDH и ML-KEM, соответственно. Общий секрет K является выводом функции HASH для конкатенации двух общих секретов K_CL и K_PQ

      K = HASH(K_PQ || K_CL)

Это похоже на логику TLS 1.3 [RFC9954], но отличается от неё (для эффективности). В [RFC9954] выполняется конкатенация секретов из классического и пост-квантового обмена, которая применяется в планировании ключей, а здесь секреты объединяются и хэшируются до использования в методологии вывода ключей SSH.

Общий секрет ECDH традиционно представлялся как целое число (mpint) в [RFC4253], [RFC5656], [RFC8731] и применялся при выводе ключа. В этой спецификации два общих секрета K_PQ и K_CL передаются хэш-функции для вывода K, но кодируются как массивы байтов фиксированного размера, а не целые числа. Массивы байтов определены в разделе 5 [RFC4251]. В частности, для K_CL преобразование mpint в массив байтов выполняется принятием значения mpint, которое будет давать соответствующий автономный метод обмена ключами, и его кодированием в массив байтов фиксированного размера (32 для Curve25519 и secp256r1, 48 для secp384r1) с порядком big-endian.

2.5. Вывод ключей

Ключи шифрования должны выводиться из общего секрета K в соответствии с параграфом 7.2 в [RFC4253] с изменением хэша обмена H. Хэш гибридного обмена ключами PQ/T H является результатом применения функции HASH, заданной именем метода гибридного обмена PQ/T, к конкатенации указанных ниже значений.

         string V_C, строка идентификации клиента (без CR и LF)
         string V_S, строка идентификации сервера (без CR и LF)
         string I_C, содержимое клиентского сообщения SSH_MSG_KEXINIT
         string I_S, содержимое серверного сообщения SSH_MSG_KEXINIT
         string K_S, открытый ключ серверного хоста
         string C_INIT, строка октетов сообщения клиента
         string S_REPLY, строка октетов сообщения сервера
         string K, общий секрет SSH

Общий секрет K, применяемый в H, традиционно представлялся целым числом (mpint) в [RFC4253], [RFC5656], [RFC8731]. В этой спецификации K — это результат функции хэширования для конкатенации двух массивов байтов (параграф 2.4), который не является целым числом. K представляется в виде строки с использованием процесса, описанного в разделе 5 [RFC4251], а затем вместе с другими данными H передаётся функции хэширования HASH для генерации ключей шифрования.

3. Размер сообщения

Реализации SSH, соответствующие [RFC4253], должны поддерживать пакеты с размером несжатого содержимого до 35000 байтов (включая packet_length, padding_length, payload, random padding, mac). Это значение представляет то, что по минимуму должны поддерживать приложения SSH. Хотя некоторые пост-квантовые схемы обмена ключами могут создавать более длинные сообщения, этот документ не задаёт методов (параграф 2.3), которые могут приводить к превышению значений, заданных в параграфе 6.1 [RFC4253]. Таким образом, документ не задаёт нового поведения для случаев, когда сообщения гибридного обмена ключами PQ/T вызовут превышение пакетом минимального поддерживаемого размера.

4. Взаимодействие с IANA

Агентство IANA зарегистрировало приведённые в таблице 1 имена методов в реестре Key Exchange Method Names группы Secure Shell (SSH) Protocol Parameters [IANA-SSH].

Таблица 1. Имена новых методов обмена ключами.

 

Имя

Документ

Реализация

mlkem768nistp256-sha256

RFC 10042

следует

mlkem1024nistp384-sha384

RFC 10042

следует

mlkem768x25519-sha256

RFC 10042

следует

 

5. Вопросы безопасности

Соображения безопасности, отмеченные в [RFC5656] и [RFC8731], применимы и к ECDH в заданных здесь гибридных схемах обмена ключами PQ/T.

Поскольку сегодня обычно применяются ключи (EC)DH, эта спецификация требует генерации эфемерных пар ключей при обмене ECDH и ML-KEM на каждое соединение. Кроме того, реализациям недопустимо неоднократно использовать случайные значения при генерации шифротекстов ML-KEM. Напомним, что свойства безопасности протокола из этого документа, SSH и применяемые криптоалгоритмы, включая ML-KEM, зависят от доступности и надлежащего применения криптографически безопасных случайных данных. Генерация качественных случайных чисел для традиционных пар и ML-KEM, а также шифротекста ML-KEM может быть трудной. Дополнительные сведения о генерации случайных значения для ML-KEM приведены в параграфе 3.3 [FIPS203].

Реализации должны применять для K_PQ, K_CL и K указанное в документе кодирование, чтобы предотвратить возможные атаки по побочным каналам. Способ кодирования выведенной двоичной строки (т. е. добавления или удаления нулевых байтов) перед хэшированием может приводить к секретам переменного размера, что повышает вероятность атак по побочному каналу. При удлинении секрета хэш-функции может потребоваться внутренняя обработка большего числа блоков, что может раскрывать размер хэшируемых данных. Это может привести к утечке старшего бита выведенного секрета и/или обнаружению случаев, когда старшие байты имеют значение 0. В некоторых нежелательных обстоятельствах это приводит к атакам по времени, например, Lucky Thirteen [LUCKY13] и Raccoon [RACCOON]. В [RFC8731] и [RFC5656] общие секреты были числами mpint и целыми числами с фиксированным размером, что открывало возможности для таких атак по побочным каналам. В этом документе проблема решается за счёт кодирования K_PQ и K_CL в битовые массивы фиксированного размера, а K — в строку.

В [PQ-PROOF] и [PQ-PROOF2] приведены доказательства безопасности схем гибридного обмена ключами PQ/T. В [PQ-PROOF2] обсуждается, как можно доказать безопасность используемого в документе сочетания ключей для вывода K и симметричных ключей SSH для IND-CPA и IND-CCA2 с некоторыми допущениями. Безопасность IND-CPA обеспечивается при условии вызова HASH как KDF, что вполне допустимо, а для IND-CCA2 предполагается, что HASH является случайным оракулом, что является более сильным допущением, особенно для вариантов семейства SHA-2, вносящих риск увеличения размера. В качестве функции HASH, более подходящей в качестве случайного оракула, можно взять SHAKE256 или внести HMAC-SHA-256, как в вариантах (2b) и (2c) из Приложения A. В документе применяется широко используемая функция SHA-2, хотя для доказательства IND-CCA2 нужны более строгие допущения, поскольку даже для традиционном выводе ключей SSH не существует доказательства IND-CCA2.

Традиционный обмен ключами с эллиптической кривой X25519 в одном из заданных здесь гибридных методов PQ/T обычно считается более простым для безопасной реализации без побочных каналов, чем варианты NIST (с P256 и P384). Исторически реализации с P256 и P384 сталкивались с проблемами, которые со временем были решены. Оптимизированные реализации X25119 эффективней реализаций P256 и P384. X25519 шире распространен в криптосистемах, чем P256 и P384. Кривые NIST иногда предпочтительней из-за требований регуляторов.

6. Литература

6.1. Нормативные документы

[FIPS203] NIST, «Module-Lattice-Based Key-Encapsulation Mechanism Standard», NIST FIPS 203, DOI 10.6028/NIST.FIPS.203, 13 August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4251] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC5656] Stebila, D. and J. Green, «Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer», RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, «US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)», RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, «Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448», RFC 8731, DOI 10.17487/RFC8731, February 2020, <https://www.rfc-editor.org/info/rfc8731>.

6.2. Дополнительная литература

[CHEMPAT] Josefsson, S., «Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms», Work in Progress, Internet-Draft, draft-josefsson-chempat-05, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-05>.

[IANA-SSH] IANA, «Secure Shell (SSH) Protocol Parameters», <https://www.iana.org/assignments/ssh-parameters>.

[LUCKY13] Al Fardan, N.J. and K.G. Paterson, «Lucky Thirteen: Breaking the TLS and DTLS record protocols», 2013 IEEE Symposium on Security and Privacy, pp. 526-540, DOI 10.1109/SP.2013.42, 2013, <https://ieeexplore.ieee.org/iel7/6547086/6547088/06547131.pdf>.

[NIST-SHA2] NIST, «Secure Hash Standard (SHS)», NIST FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

[NIST-SP800-186] Chen, L., Moody, D., Randall, K., Regenscheid, A., and A. Robinson, «Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters», National Institute of Standards and Technology, NIST SP 800-186, DOI 10.6028/NIST.SP.800-186, February 2023, <https://doi.org/10.6028/NIST.SP.800-186>.

[NIST-SP-800-56C] Barker, E., Chen, L., and R. Davis, «Recommendation for Key-Derivation Methods in Key-Establishment Schemes», National Institute of Standards and Technology, NIST SP 800-56Cr2, DOI 10.6028/NIST.SP.800-56Cr2, August 2020, <https://doi.org/10.6028/NIST.SP.800-56Cr2>.

[NIST-SP-800-133r2] Barker, E., Roginsky, A., and R. Davis, «Recommendation for Cryptographic Key Generation», National Institute of Standards and Technology, NIST SP 800-133r2, DOI 10.6028/NIST.SP.800-133r2, June 2020, <https://doi.org/10.6028/NIST.SP.800-133r2>.

[NIST-SP-800-135] Dang, Q., «Recommendation for Existing Application-Specific Key Derivation Functions», National Institute of Standards and Technology, NIST SP 800-135r1, DOI 10.6028/NIST.SP.800-135r1, December 2011, <https://doi.org/10.6028/NIST.SP.800-135r1>.

[NIST-SP-800-227] Alagic, G., Barker, E., Chen, L., Dustin, D., Robinson, A., Silberg, H., and N. Waller, «Recommendations for Key-Encapsulation Mechanisms», National Institute of Standards and Technology, NIST SP 800-227, DOI 10.6028/NIST.SP.800-227, September 2025, <https://doi.org/10.6028/NIST.SP.800-227>.

[NIST_PQ] NIST, «Post-Quantum Cryptography (PQC)», 5 August 2026, <https://csrc.nist.gov/projects/post-quantum-cryptography>.

[OAM-CONS] Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, «Guidelines for Considering Operations and Management in IETF Specifications», Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-06, 12 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-06>.

[PQ-PROOF] Campagna, M. and A. Petcher, «Security of Hybrid Key Encapsulation», Cryptology ePrint Archive, Paper 2020/1364, 2020, <https://eprint.iacr.org/2020/1364>.

[PQ-PROOF2] Petcher, A. and M. Campagna, «Security of Hybrid Key Establishment using Concatenation», Cryptology ePrint Archive, Paper 2023/972, 2023, <https://eprint.iacr.org/2023/972>.

[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J., Mittmann, J., and J. Schwenk, «Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)», September 2020, <https://raccoon-attack.com/>.

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Assigned Numbers», RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, «Elliptic Curves for Security», RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.

[RFC9794] Driscoll, F., Parsons, M., and B. Hale, «Terminology for Post-Quantum Traditional Hybrid Schemes», RFC 9794, DOI 10.17487/RFC9794, June 2025, <https://www.rfc-editor.org/info/rfc9794>.

[RFC9941] Friedl, M., Mojzis, J., and S. Josefsson, «Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512», RFC 9941, DOI 10.17487/RFC9941, April 2026, <https://www.rfc-editor.org/info/rfc9941>.

[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, «Hybrid Key Exchange in TLS 1.3», RFC 9954, DOI 10.17487/RFC9954, July 2026, <https://www.rfc-editor.org/info/rfc9954>.

[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, «Post-Quantum Cryptography for Engineers», RFC 9958, DOI 10.17487/RFC9958, June 2026, <https://www.rfc-editor.org/info/rfc9958>.

[XWING-KEM] Connolly, D., Schwabe, P., and B. Westerbaan, «X-Wing: general-purpose hybrid post-quantum KEM», Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-10, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-10>.

Приложение A. Другие сумматоры

В процессе работы над документом рассматривались другие сумматоры для вывода K и ключей SSH.

  1. K = K_PQ || K_CL. Все ключи SSH выводятся из K в соответствии с параграфом 7.2 в [RFC4253].

  2. Все ключи SSH выводятся из K в соответствии с параграфом 7.2 в [RFC4253].

    1. K = HASH(K_PQ, K_CL). Этот вариант принят в данной спецификации.

    2. K = HMAC-HASH(K_PQ, K_CL)

    3. K = HMAC-HASH(0, K_PQ || K_CL)

  3. K = HKDF-HASH_Extract(0, K_PQ || K_CL). Ключи SSH выводятся из K с использованием HKDF-HASH(K, H || session_id, 6*sizeof(HASH)).

Вариант (3) основан на логике извлечения (Extract-and-Expand) из [NIST-SP-800-56C]. Он существенно отличается от принятого в SSH вывода ключей и может считаться слишком далёким от текущей архитектуры SSH. Возможно, хорошим подходом для SSH был бы переход от повсеместного применения хэширования к подходящей функции KDF с извлечением (extract/expand), но это требует отдельных усилий.

Рассмотрены комбинации, подобные предложенным в [CHEMPAT] и [XWING-KEM]. Для [XWING-KEM] имеется отдельное доказательство IND-CCA2. Хотя можно доказать для таких сумматоров безопасность IND-CCA2, для вывода ключей доказательство IND-CCA2 SSH требует допущений, изложенных в [PQ-PROOF2] и рассмотренных в разделе 5.

Приложение B. FIPS

В [NIST-SP-800-56C] и [NIST-SP-800-135] приведены рекомендации NIST по методам вывода ключей в протоколах обмена. Некоторые гибридные комбинации PQ/T сочетают общий секрет из утверждённого NIST алгоритма (например, ECDH применяет кривую nistp256/secp256r1 или ML-KEM) с общим секретом из алгоритма, который не входит в число утверждённых (например, X25519). В [NIST-SP-800-227] указана простая конкатенация как одобренный способ создания общего секрета в гибридном методе PQ/T, где один из компонентов секрета взят из утверждённого алгоритма (например, secp256r1, secp384r1, ML-KEM) и применяется в методе вывода/сочетания, утверждённом [NIST-SP-800-56C] или [NIST-SP-800-133r2]. Хотя функция вывода ключей SSH не следует рекомендациям [NIST-SP-800-56C] и [NIST-SP-800-133r2], она одобрена [NIST-SP-800-135]. Этот метод совпадает с примененным в документе методом вывода ключей SSH из квантово-стойкого общего секрета. Таким образом, сумматор ключей SSH из этого документа можно, по-видимому, считать одобренным FIPS, хотя это и не указано в [NIST-SP-800-227].

Благодарности

Авторы признательны Gerardo Ravago из AWS за реализацию и обнаружение проблемных вопросов. Спасибо Damien Miller и Markus Friedl за их отклики и реализацию некоторых из описанных здесь методов обмена ключами SSH в OpenSSH. Отдельная благодарность Simon Tatham из Putty, Loganaden Velvindron, John Mattsson, Simon Josefsson и Watson Ladd за их значимые предложения.

Адреса авторов

Panos Kampanakis

AWS

Email: kpanos@amazon.com

Douglas Stebila

University of Waterloo

Email: dstebila@uwaterloo.ca

Torben Hansen

AWS

Email: htorben@amazon.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В оригинале ошибочно сказано «клиент». Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий