Кратко

  • RFC 10024 задаёт три финальные группы TLS 1.3 с фиксированными порядком, длинами и проверками для секретов ECDHE и ML-KEM.
  • Цель сохранить секрет при стойкости хотя бы одного компонента относится к криптографической конструкции. Сам RFC отдельно предупреждает: один небезопасный RNG способен связать безопасность обоих алгоритмов.
  • Для доказательства миграции нужны не только группа и transcript, но и карта энтропии, процесса, библиотеки, памяти, модуля, реальной точки терминации, FIPS-границы и схемы подписи.

Аварийный откат не различал компоненты

Представим, что после обновления криптографической библиотеки на части узлов растёт доля ошибок. Дежурная команда запускает заранее подготовленный откат. Через несколько минут метрики снова зелёные, а ServerHello по-прежнему показывает X25519MLKEM768. На панели ничего принципиально не изменилось: соединения остались гибридными.

Однако откат одновременно заменил реализацию ML-KEM, код X25519 и общий сервис случайных чисел. Он вернул старую обработку снимков виртуальной машины, при которой после восстановления не всегда выполнялось немедленное повторное засевание CSPRNG. Два алгоритма продолжили согласовываться как одна стандартная группа, но их общий эксплуатационный корень стал слабее.

Это гипотетический пример, а не сообщение об уязвимости продукта. Общий исправный CSPRNG сам по себе не делает гибрид небезопасным. Пример показывает другое: механизм аварийного управления может связать компоненты сильнее, чем это видно из названия группы.

RFC 10024 опубликован на треке стандартов IETF в августе 2026 года. Он определяет три Post-Quantum Traditional механизма согласования ключей для TLS 1.3. Каждый сочетает эфемерный обмен на эллиптической кривой с ML-KEM. Замысел состоит в том, чтобы общий секрет оставался защищённым, пока хотя бы один компонентный механизм сохраняет стойкость.

Это существенная криптографическая гарантия в пределах сформулированных предпосылок. Она не описывает архитектуру процессов, модулей и полномочий оператора.

Группа фиксирует не перечень, а конструкцию

В модели RFC 9954 комбинация не является двумя независимо согласованными расширениями. Она представлена как одна непрозрачная NamedGroup. Публичные значения или шифртексты компонентов соединяются в заданном порядке. Секреты фиксированной длины соединяются так же и занимают в расписании ключей TLS 1.3 место обычного секрета (EC)DHE.

У X25519MLKEM768, значение IANA 4588, первым идёт ML-KEM. Клиент отправляет 1 184 байта ключа инкапсуляции ML-KEM-768 и 32 байта X25519 — всего 1 216. Сервер возвращает 1 088 байт шифртекста ML-KEM и 32 байта X25519 — всего 1 120. Секрет состоит из 32 байт ML-KEM, а затем 32 байт X25519.

SecP256r1MLKEM768, значение 4587, начинается с P-256. Доля клиента — 65 байт несжатой точки и 1 184 байта ML-KEM; доля сервера — 65 и 1 088 байт. Секрет содержит 32 байта ECDHE, затем 32 байта ML-KEM.

SecP384r1MLKEM1024, значение 4589, сочетает 97-байтную точку P-384 с 1 568 байтами ML-KEM-1024. Key share обеих сторон имеет длину 1 665 байт. Итоговый секрет содержит 48 байт ECDHE и 32 байта ML-KEM.

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

Transcript связывает выбор с конкретной сессией

Действующая спецификация TLS 1.3 — RFC 9846 — включает ClientHello, возможный HelloRetryRequest, второй ClientHello, ServerHello и последующие сообщения аутентификации в transcript. Выбранный сервером key share определяет вход секрета в расписание ключей. CertificateVerify подписывает transcript, а Finished доказывает владение производными ключами.

RFC 10024 прямо указывает, что его анализ безопасности критически зависит от transcript TLS 1.3. Значит, доказательство находится не в самом действии конкатенации, а в связанном ходе согласования и аутентификации.

RFC 9794 уточняет терминологию. Гибридная схема PQ/T включает как минимум один постквантовый и один традиционный компонент. Термин «постквантовый» обозначает целевое свойство, но не гарантирует отсутствие будущей классической или квантовой атаки.

Поэтому рабочая запись должна соединять предложенные группы, отправленные key shares, факт HelloRetryRequest, выбранную ServerHello группу, результаты проверок, схему подписи CertificateVerify и завершение Finished. Запись «функция включена» в конфигурации фиксирует намерение, а не выполненный обмен.

Проверки значений не проверяют среду исполнения

RFC 10024 требует от сервера проверить ключ инкапсуляции ML-KEM клиента по FIPS 203 и при неудаче завершить обмен с illegal_parameter. Клиент проверяет длину шифртекста. Компоненты ECDHE выполняют проверки допустимости; X25519 отвергает полностью нулевой общий секрет. Иная ошибка декапсуляции ML-KEM ведёт к internal_error.

Такие отказы необходимы: некорректный материал не должен незаметно стать основой сессии. Но они не аттестуют источник случайности, защиту от побочных каналов, разделение памяти, цепочку поставки или фактическую точку TLS-терминации.

FIPS 203 стандартизует ML-KEM-512, 768 и 1024 и говорит, что ML-KEM считается стойким против противника с квантовым компьютером. Осторожная формулировка важна: стандарт не отменяет требований к реализации, случайности, параметрам и дальнейшему криптоанализу.

NIST SP 800-227 даёт более широкие рекомендации по безопасной реализации и использованию KEM, включая комбинированные конструкции. Ссылка на руководство не доказывает, какие меры принял конкретный производственный бинарный файл.

Общий RNG — прямо названная граница

При инкапсуляции ML-KEM сервер получает случайное значение m, которое клиент восстанавливает при декапсуляции. RFC 10024 отмечает: если m несёт информацию о других выходах генератора, клиент получает эту информацию. Эфемерные скаляры ECDHE также требуют криптографически безопасной случайности, хотя сам скаляр не передаётся.

Далее спецификация формулирует эксплуатационное следствие: если оба алгоритма используют один и тот же небезопасный RNG, раскрытие его состояния через один алгоритм влияет на безопасность другого.

Слово «небезопасный» нельзя терять. Корректно спроектированный, засеянный, повторно засеваемый и защищённый CSPRNG не ломается только из-за совместного использования. RFC не требует и двух физических источников. Он требует понимать зависимость: исходную энтропию, seed и reseed, fork, snapshot, восстановление, health checks, память и наблюдаемые выходы.

RFC 8937 объясняет, как дефектная исходная энтропия может одновременно ослабить все засеянные от неё экземпляры. Документ предлагает, в частности, необязательную обёртку с примесью материала от операции с долговременным закрытым ключом для усиления случайности между сессиями. Выбор меры остаётся локальным, а необходимость показать фактическую цепочку — нет.

Случайность — явный пример из RFC. Общая уязвимость библиотеки, firmware HSM, пространство памяти, ключ сборки или административная учётная запись также способны пересечь оба компонента. Это не дефект математической комбинации, а граница того, что её доказательство может утверждать о работающей системе.

Порядок FIPS назначает узкую обязанность

RFC 10024 описывает условие NIST для подачи в HKDF двух разных секретов: первый должен происходить от одобренной FIPS схемы установления ключа. В SecP256r1MLKEM768 и SecP384r1MLKEM1024 первым идёт ECDHE. Для описанного использования реализация ECDHE должна быть сертифицирована, тогда как само условие порядка не требует сертификации реализации ML-KEM. В X25519MLKEM768 первым идёт ML-KEM, поэтому сертификации подлежит его реализация.

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

Регистрация IANA не подтверждает внедрение

Реестр TLS Supported Groups IANA присваивает финальным группам значения 4587, 4588 и 4589. Только X25519MLKEM768 имеет Recommended Y; две secp-комбинации отмечены N. Примечание IANA поясняет, что N не обязательно указывает на изъян: назначение может быть ограниченным или специальным.

Экспериментальные draft-группы Kyber 25497 и 25498 помечены устаревшими и не рекомендуются. Наблюдаемость должна отличать их от финальных кодов, а не сводить разные wire semantics к метке «PQC».

Реестр создаёт общее имя. Конфигурация показывает локальное намерение. ClientHello показывает предложение. ServerHello и transcript показывают выбор для одного соединения. Покрытие флота подтверждается только измерением флота.

Официальный поиск errata для RFC 10024 30 августа 2026 года не показывал записей. Это датированное состояние реестра, а не гарантия каждой реализации.

Подпись сертификата идёт отдельным маршрутом

RFC 9954 прямо исключает аутентификацию следующего поколения из области действия. TLS 1.3 отделяет согласование ключей от Certificate и CertificateVerify. Соединение может правильно выбрать X25519MLKEM768, но аутентифицировать сервер традиционной подписью.

Гибридный обмен отвечает на риск «собрать сегодня, расшифровать потом». Будущая подделка идентичности и миграция сертификатов имеют иной график. Группа, подпись, реальная точка терминации и решение приложения должны оставаться отдельными полями, а не исчезать в заявлении «PQC завершён».

Принцип Heng Lu Running-Code Primacy задаёт иерархию доказательств: выполненный transcript и наблюдаемый результат важнее символа в панели управления. Доктрина минимальной исходной спецификации и локального будущего решения объясняет, почему общий стандарт определяет совместимость, но не диктует каждому оператору архитектуру отказа.

Анализ слоёв реальности и символической власти отделяет слово «гибридный» от исполняемых операций. Анализ технического и практического контроля данных спрашивает, кто действительно может изменить терминатор, библиотеку, энтропию, телеметрию и откат. Эти полномочия и образуют рабочую границу.

Стандарт правильно объединяет два секрета. Организация обязана показать, что один аварийный механизм не выбирает судьбу обоих.