Кратко

  • RFC 10042 — информационный документ IETF авторства Panos Kampanakis, Douglas Stebila и Torben Hansen. Он определяет три SSH-метода, объединяющих ML-KEM с P-256, P-384 или X25519.
  • В гибридном ответе сервера по-прежнему передаются открытый ключ хоста и подпись обменного хэша. Затем отдельный протокол аутентифицирует пользователя: KEX, хост и пользователь требуют разных подтверждений.
  • В примере SFTP от AWS журнал разносит по отдельным строкам гибридный KEX, алгоритм и отпечаток ключа хоста, а позже — вход пользователя по открытому ключу.

Итог SSH-сеанса выглядит бинарно: подключение состоялось или оборвалось. Для инженера этого мало. Перед появлением приглашения или передачей файла протокол выполнил три разных проверки.

Сначала стороны выбрали способ получить секрет транспортного шифрования. Затем клиент решил, какому серверному ключу доверять. После этого сервер проверил пользователя и его право на службу. В каждой части есть ключи и подписи, но субъекты и последствия не совпадают.

RFC 10042 усиливает первую часть. Документ опубликован в августе 2026 года в категории Informational и определяет mlkem768nistp256-sha256, mlkem1024nistp384-sha384 и mlkem768x25519-sha256. Методы объединяют секрет ML-KEM с результатом классического обмена на P-256, P-384 или X25519.

Назначение — снизить риск «собрать сейчас, расшифровать потом». Противник может сохранить зашифрованный трафик и ждать квантовой возможности взломать классическое установление ключа. Гибрид связывает секрет сеанса с двумя семействами. Это серьёзная защита для транспорта, но не автоматическая проверка личности.

Ключ хоста остался на месте

Формат ответа сервера прямо фиксирует границу. Клиент отправляет временные классические и постквантовые открытые данные. Сервер возвращает ciphertext ML-KEM и свой классический открытый элемент, а вместе с ними K_S — открытый ключ хоста — и подпись обменного хэша.

Секрет K вычисляется как хэш сцепления постквантового и классического секретов. В обменный хэш входят строки версий, оба SSH_MSG_KEXINIT, ключ хоста, гибридные значения и K. Сервер подписывает его закрытым ключом хоста.

Операции связаны одним transcript, но отвечают на разные вопросы. KEX создаёт свежий секрет для транспорта. Подпись связывает transcript с определённым серверным ключом. Клиенту всё равно нужен источник, подтверждающий, что этот ключ принадлежит нужному адресу.

RFC 4253 согласовывает kex_algorithms и server_host_key_algorithms отдельными списками. Доверие может исходить из known_hosts, проверенного другим каналом отпечатка или сертификата. Принять ключ без проверки значит сохранить уязвимость для активной атаки. Компонент ML-KEM не исправляет пропущенное решение об идентичности.

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

Пользователь входит через другой контур

После создания транспорта направление проверки меняется. Теперь сервер оценивает пользователя. RFC 4252 описывает эту аутентификацию поверх транспортного слоя. Реализации обязаны поддерживать publickey; пароль и hostbased опциональны, возможны и расширения.

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

Это не повторение ключа хоста. Хостовый ключ помогает клиенту узнать сервер. Пользовательский ключ помогает серверу узнать человека или процесс. authorized_keys, каталог идентичностей, блокировка учётной записи, MFA, принудительная команда и права на каталоги SFTP находятся за пределами KEX.

Миграция может идти поэтапно: сначала KEX, потом подписи хоста, затем пользовательские данные. Этапность честна, пока результат первого этапа не выдают за доказательство завершения остальных.

Три строки в журнале AWS

Статья AWS о гибридном SFTP даёт практический образец. Исходный пример 2023 года использовал экспериментальные названия Kyber. Обновление от 5 сентября 2025 года сообщает, что две политики AWS Transfer Family перешли на ML-KEM, и перечисляет три названия, опубликованные позднее в RFC 10042.

Старый лог нельзя называть сеансом RFC 10042. Он полезен как схема наблюдения. Сначала указан гибридный KEX, отдельно — ssh-ed25519 как алгоритм хоста и отпечаток сервера. Позже появляется аутентификация пользователя методом publickey, и лишь затем открывается SFTP-сеанс.

Оператор получает три воспроизводимых вопроса:

  1. Какие методы были предложены, какой выбран и дошёл ли обмен до новых ключей?
  2. Какой ключ хоста подписал transcript и почему клиент ему доверял?
  3. Какая пользовательская аутентификация сработала, для какого аккаунта и с какими правами?

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

Переход от экспериментальных имён к ML-KEM показывает и проблему жизненного цикла. Клиенты, серверы, встроенные устройства и автоматизация обновляются не одновременно. Версия, порядок предпочтений и fallback решают судьбу конкретного соединения. Строка IANA с SHOULD — координата совместимости, а не статистика Интернета.

Узкая спецификация как инженерное преимущество

Amazon Science называет Kampanakis principal security engineer в AWS и связывает его работу с прикладной криптографией, автоматизацией безопасности и стандартами. В профиле AWS 2023 года он советовал инвентаризировать асимметричную криптографию, проверять влияние новых алгоритмов на SSH и другие сценарии, сохранять алгоритмическую гибкость. Там же он отличал контролируемый прототип от долгосрочной поддержки в масштабе.

Это объясняет контекст, но не создаёт единоличное авторство. Stebila и Hansen — соавторы. RFC отмечает реализацию и рецензирование со стороны участников AWS, OpenSSH, PuTTY и других. ML-KEM стандартизован NIST, а IETF и IANA задают общие протокольные координаты.

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

Принцип минимальной начальной спецификации Heng Lu помогает увидеть в этой границе достоинство. Общий стандарт не должен управлять каждым хранилищем доверия и каждой учётной записью. Будущие решения остаются у операторов. Принцип приоритета работающего кода требует сохранять наблюдаемый результат, а не ярлык.

В полноценное подтверждение входят версии, предложенные и выбранные KEX, алгоритм и отпечаток хоста, решение о доверии, шифр и MAC, NEWKEYS, метод пользователя, авторизация, открытый канал, rekey, fallback, ошибки и слепые зоны измерения.

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

Источники