Кратко

  • RFC 10042 вводит три метода ML-KEM/ECDH для транспортного уровня SSH и получает K из двух эфемерных общих секретов.
  • Подписанный обмен может подтвердить конкретный этап установления ключа; доверие к K_S, аутентификация пользователя и разрешённое действие требуют других локальных доказательств.

В гибридном ответе есть всё, что легко принять за единый вердикт: ключ хоста K_S, материал двух криптографических схем и подпись хэша обмена. Но RFC 10042 намеренно описывает только один слой. Клиент отправляет SSH_MSG_KEX_HYBRID_INIT с C_INIT, объединяющим публичный ключ ML-KEM и классический публичный ключ. Сервер возвращает SSH_MSG_KEX_HYBRID_REPLY, K_S, строку S_REPLY из ML-KEM ciphertext и классического публичного ключа, а также подпись. Стороны получают K_PQ и K_CL, кодируют их как фиксированные массивы байтов и хэшируют в общий секрет K.

Здесь важны не только названия алгоритмов, но и отрицательные условия. Сервер обязан до encapsulation проверить ожидаемую длину C_INIT; клиент обязан до decapsulation проверить длину S_REPLY. Ошибка длины или decapsulation требует отключения с причиной ошибки обмена ключами. Для каждого соединения нужны новые эфемерные пары ECDH и ML-KEM, а случайность ML-KEM ciphertext нельзя использовать повторно. Фиксированная длина снижает риск того, что длина секрета станет побочным сигналом.

Такое событие можно проверить как событие обмена ключами. Из него нельзя вывести, что клиент доверял нужному хосту. Архитектура SSH действительно использует ключ хоста и подпись для аутентификации сервера на транспортном уровне. Однако RFC 4251 требует от клиента предварительного знания публичного ключа сервера: через локальную базу соответствий имени и ключа либо через сертификат от принятого центра. RFC 4253 прямо описывает проверку K_S по сертификату или локальной базе и предупреждает, что принятие без проверки оставляет защиту уязвимой к активной атаке. RFC 10042 не задаёт источник этой привязки и не решает, какой ключ должен принять конкретный клиент.

В этом же состоит граница журнала KEX. Его хэш включает идентификационные строки, обе нагрузки KEXINIT, K_S, C_INIT, S_REPLY и K. Он связывает именно эти входы в обмене и последующей деривации SSH. В нём нет запроса SSH_MSG_USERAUTH_REQUEST, сопоставления учётной записи, правила авторизации, запроса канала или результата команды. RFC 4251 отделяет пользовательскую аутентификацию от transport layer и оставляет серверной локальной политике выбор допустимых методов и доступа.

Три зарегистрированных имени — mlkem768nistp256-sha256, mlkem1024nistp384-sha384 и mlkem768x25519-sha256 — полезны как точная номенклатура. Инвентарь может подтвердить поддержку, KEXINIT — предложение, а проверенный transcript — выбор и завершённый обмен. Но даже полный набор этих фактов не является записью о пользователе или праве. Порядок сообщений SSH различает область key exchange и SSH_MSG_USERAUTH_*; эксплуатационная телеметрия должна сохранять то же различие.