Постквантовая миграция в 2026 году: план для разработчиков

Коротко. В 2026 году значительная часть постквантовой работы по шифрованию данных при передаче сводится к обновлению. Chrome, Firefox, релизы Apple версии 26, OpenSSL 3.5, Go 1.24+, JDK 27 и OpenSSH 10 по умолчанию согласуют гибридный обмен ключами ML-KEM. Ваша задача — найти соединения, где этого всё ещё не происходит: старые библиотеки, жёстко заданные списки групп, промежуточные устройства (middleboxes), TLS 1.2, VPN, внутренние сервисы. Подписи и сертификаты — медленная часть работы. Публичные центры сертификации (CA) пока не могут выпускать сертификаты ML-DSA для браузеров, поэтому уже сейчас проведите инвентаризацию, опробуйте ML-DSA в частной PKI и проектируйте системы с расчётом на смену алгоритмов. Ориентиры для планирования — даты из проекта NIST IR 8547: ключи со стойкостью 112 бит, такие как RSA-2048, объявляются устаревшими после 2030 года, а все уязвимые для квантового компьютера алгоритмы с открытым ключом запрещаются после 2035 года. CNSA 2.0 от NSA устанавливает более ранние сроки для систем национальной безопасности США.

Две проблемы с разными сроками

Криптографически значимый квантовый компьютер с помощью алгоритма Шора взломал бы RSA, протокол Диффи — Хеллмана в конечных полях и криптографию на эллиптических кривых (ECDH, ECDSA, EdDSA). Симметричная криптография и хеш-функции остаются стойкими при сегодняшних размерах ключей: AES-256 и SHA-256 или больше. Никто не может сказать, когда появится такая машина. На странице проекта OpenSSH опубликованные оценки подытожены так: «5–20 лет, причём многие наблюдатели ожидают появления таких компьютеров в середине 2030-х годов». Миграция распадается на две проблемы с очень разной срочностью:

• Конфиденциальность: это срочно. Зашифрованный трафик, записанный сегодня, можно будет расшифровать, как только появится квантовый компьютер. Так работает схема «собери сейчас, расшифруй потом» (harvest now, decrypt later). Всё, что должно оставаться секретным дольше нескольких лет, уже под угрозой, если для этого используется классический обмен ключами. Решение — постквантовый обмен ключами, и развернуть его можно уже сегодня.
• Аутентификация: здесь есть крайний срок. Поддельная подпись имеет значение, только когда на неё кто-то полагается, поэтому квантовый компьютер должен существовать именно в этот момент. Но ключи подписи и якоря доверия живут долго. Корневым сертификатам, ключам прошивок, ключам подписи кода и архивным подписанным документам доверяют десятилетиями, а их замена занимает годы.

Планируйте работу в этом порядке: сначала обмен ключами, затем подписи.

Какие сроки установлены на самом деле

Три замечания к этой таблице:

1. IR 8547 — всё ещё проект. На даты 2030 и 2035 годов в своих планах ориентируются ведомства и поставщики, но окончательной политикой NIST они пока не стали. В проекте «устаревший» (deprecated) означает, что алгоритм ещё можно использовать, если вы принимаете риск, а «запрещённый» (disallowed) — что использовать его нельзя вовсе.
2. Этап 2030 года затрагивает 112-битные ключи, прежде всего RSA-2048. RSA-2048 по-прежнему используется во многих сертификатах и во многих сервисах, которые подписывают токены (2 из 6 эндпоинтов в сканировании ниже работают именно с ним). P-256 и RSA-3072 обеспечивают стойкость 128 бит и остаются допустимыми до 2035 года, но переход на них даёт не больше 5 лет, потому что после 2035 года проект запрещает всё, что уязвимо для квантового компьютера.
3. Для гибридных схем важна сноска CNSA 2.0. Гибридные режимы разрешены, но алгоритмы CNSA 2.0 «станут обязательными к выбору с указанной даты», поэтому конфигурация только с классическими алгоритмами перестаёт быть допустимой.

Что уже по умолчанию использует постквантовые алгоритмы

Эти компоненты согласуют гибридный обмен ключами ML-KEM без какой-либо настройки, если обе стороны достаточно свежие:

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

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

Главное видно по двум столбцам. Обмен ключами неоднороден: у одних сервисов гибрид есть, у других нет. В столбцах сертификатов везде классические алгоритмы: ECDSA P-256 или RSA-2048. То же верно и для SSH, где GitHub уже выбирает гибрид для клиента OpenSSH 10:

debug1: kex: algorithm: mlkem768x25519-sha256

Шаг 1: инвентаризация

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

Начните с того, что можно измерить снаружи, — с ваших TLS-эндпоинтов:

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

Запускать скрипт нужно обязательно с клиентом OpenSSL 3.5: старые клиенты никогда не предлагают гибрид, и для них любой сервер выглядит классическим. Чтобы проверить много доменов сразу, воспользуйтесь массовой проверкой доменов: она показывает обмен ключами, алгоритмы сертификата и срок действия для каждого хоста.

Затем переходите к внутренней инфраструктуре, где и находится основная часть работы:

• Библиотеки и среды выполнения. Перечислите версии OpenSSL, BoringSSL, Go, JDK, .NET, Node.js и Python в каждом образе и на каждом хосте. OpenSSL 3.0 больше не поддерживается основным проектом (upstream), в нём нет ML-KEM, а Ubuntu 24.04 всё ещё поставляется с ним. Один этот факт объясняет многие результаты.
• Явная конфигурация. Найдите списки групп и шифров, например ssl_ecdh_curve, SSLOpenSSLConfCmd Groups, CurvePreferences, jdk.tls.namedGroups и KexAlgorithms. Каждый из них — место, куда не дойдёт обновление значений по умолчанию.
• Код. Найдите прямые вызовы API для RSA, ECDSA, ECDH и Ed25519, размеры ключей, значения alg в JWT и открытые ключи, хранящиеся в базах данных. Подписи, сохранённые в форматах данных, потом сложнее всего изменить.
• Долгоживущие ключи и сертификаты. Корневые сертификаты частных CA, ключи подписи кода и прошивок, подпись документов, CA для SSH, ключи, хранящиеся в HSM. Для каждого запишите дату окончания срока действия и алгоритмы, которые поддерживает HSM.
• Поставщики. Балансировщики нагрузки, WAF, прокси с инспекцией TLS, VPN-концентраторы, управляемые базы данных, API SaaS-сервисов. Запросите у каждого поставщика письменную дорожную карту поддержки ML-KEM и ML-DSA.

Зафиксируйте результат в машиночитаемом виде. Именно для этого в CycloneDX появился перечень криптографических компонентов (Cryptography Bill of Materials, CBOM). Он описывает алгоритмы, ключи, сертификаты и протоколы как компоненты описи вашего ПО — рядом с SBOM пакетов, который вы, возможно, уже формируете.

Шаг 2: доведите обмен ключами до конца

Для каждой точки терминации TLS, которую вы контролируете:

1. Обновите TLS-библиотеку. OpenSSL 3.5, Go 1.24 или новее, JDK 27 либо актуальная сборка BoringSSL или AWS-LC.
2. Уберите жёстко заданные списки групп или поставьте в них X25519MLKEM768 на первое место. Строка конфигурации для усиления защиты, скопированная из старого руководства, — самая частая причина, по которой современный сервер согласует обычный X25519. Механика разобрана в статье X25519MLKEM768: как это работает.
3. Тестируйте на реальном сетевом пути. Гибридный ClientHello занимает около 1,5 КБ. Некоторые межсетевые экраны, балансировщики нагрузки и прокси с инспекцией TLS дают сбой на ClientHello, который занимает два пакета. Прежде чем винить сервер, сравните гибридное и чисто классическое рукопожатие через один и тот же путь.
4. Проверьте оба участка. За CDN или балансировщиком нагрузки соединение от пограничного узла до исходного сервера (edge-to-origin) — отдельный TLS-сеанс. Трафик на этом участке точно так же можно записать сейчас и расшифровать потом.
5. Откажитесь от TLS 1.2, где это возможно. Гибридные группы определены только для TLS 1.3.

Затем займитесь каналами за пределами веба:

• SSH. OpenSSH 9.0 и новее уже согласуют постквантовый гибрид, если его поддерживают обе стороны. Старые серверы, сетевые устройства и встроенные SSH-стеки часто этого не умеют. Клиенты OpenSSH 10.1 и новее выводят предупреждение, в котором риск назван прямо: «This session may be vulnerable to 'store now, decrypt later' attacks.»
• VPN и IPsec. IKEv2 поддерживает дополнительные обмены ключами (RFC 9370), и поставщики используют их, чтобы добавить ML-KEM. Проверьте примечания к прошивке вашего шлюза.
• Шифрование на уровне приложения. Всему, что шифрует ключи данных с помощью RSA или ECDH, — например, конвертному шифрованию, зашифрованным резервным копиям или обмену сообщениями со сквозным шифрованием, — нужен вариант с ML-KEM или гибридным KEM. Обычный строительный блок для этого — HPKE (RFC 9180) с гибридным KEM. В песочнице HPKE видно, как эти части сочетаются друг с другом.

Шаг 3: подписи и сертификаты

Здесь экосистема ещё не готова сделать всё за вас, поэтому в 2026 году работа сводится к подготовке:

• Публичные веб-сертификаты: ждите, но готовьтесь. Ни один браузер не принимает сертификаты ML-DSA от публичных CA. В феврале 2026 года Chrome сообщил, что не планирует в ближайшее время добавлять в своё хранилище корневых сертификатов сертификаты X.509 с постквантовыми ключами. Chrome создаёт отдельное квантово-устойчивое хранилище корневых сертификатов на основе сертификатов на деревьях Меркла (Merkle Tree Certificates), которые стандартизирует рабочая группа PLANTS в IETF. Пока это не готово, полезнее всего заняться автоматизацией. Команда, которая может заменить любой сертификат за минуты, легко сменит и алгоритм, а сокращение сроков действия сертификатов подталкивает в ту же сторону.
• Частная PKI: пробуйте ML-DSA уже сейчас. Внутренний mTLS, сервисные сетки (service mesh), удостоверения устройств и сертификаты VPN находятся под вашим контролем с обеих сторон. OpenSSL 3.5, Go 1.27, Java 24+, .NET 10 и BouncyCastle умеют работать с ключами и сертификатами ML-DSA. Рассчитывайте на конечный сертификат размером около 5,5 КБ с ML-DSA-65 и проверьте, что сломается: размеры буферов, ограничения на размер заголовков, поддержка в HSM. В статье ML-DSA для разработчиков есть рабочий код и разобраны подводные камни форматов ключей.
• Сначала долгоживущие якоря доверия. Корневой ключ или ключ прошивки, созданный в 2026 году, всё ещё будет считаться доверенным после 2035 года. Для подписи прошивок и обновлений ПО CNSA 2.0 требует схем на основе хеш-функций с сохранением состояния — LMS или XMSS (SP 800-208) — и ожидает, что к 2030 году будут использоваться исключительно они. SLH-DSA без сохранения состояния (FIPS 205) — консервативная альтернатива, если вы не можете управлять состоянием подписей.
• Подписанные артефакты, которые должны оставаться проверяемыми. Документы, архивы и журналы, подписанные сегодня с помощью ECDSA, нужно защитить заново до того, как их подписи перестанут заслуживать доверия. Запланируйте продление меток времени и повторное подписание архивов — так же, как это уже делает долгосрочная проверка PDF для сертификатов с истекающим сроком действия.
• Токены и API. В JOSE и COSE есть идентификаторы (code points) для ML-DSA (RFC 9964). Подпись размером 3,3 КБ увеличивает JWT в base64url примерно до 4,5 КБ, а это важно для cookie и заголовков. Прежде чем переходить, проведите измерения.

Шаг 4: сделайте следующую замену дешёвой

Миграция не будет однократным переключением. Позже гибридный обмен ключами может уступить место чистому ML-KEM. К ML-DSA может добавиться FN-DSA, который NIST планирует выпустить как FIPS 206. Составные и гибридные подписи всё ещё разрабатываются. Криптографическая гибкость — то, что не даёт каждому из этих изменений превратиться в очередной многолетний проект:

• Идентификаторы алгоритмов передаются вместе с данными (OID, alg в JOSE, байт версии), и проверяющая сторона выбирает алгоритм по ним, а не по предположению.
• Размеры ключей и подписей не зашиты в код. В столбцах, буферах и полях протоколов есть место для килобайтов.
• Ключи генерируются, хранятся и ротируются автоматически. Никто не копирует PEM-файл в конфигурацию вручную.
• Конфигурация каждого стека хранится в одном месте, поэтому следующая смена группы или алгоритма — это одна правка.

Частые ошибки

• Проверять старым клиентом. openssl s_client из OpenSSL 3.0 или curl, собранный с этой версией, никогда не предлагает гибрид. Тогда любой сервер выглядит классическим, в том числе уже переведённые на новые алгоритмы.
• Считать пограничный узел CDN всем соединением. Участок от браузера до пограничного узла часто уже постквантовый, а участок от пограничного узла до исходного сервера в том же запросе — нет.
• Отключать гибрид, чтобы починить сломанное промежуточное устройство. Так защита пропадает у всех соединений. Почините или замените устройство.
• Ничего не делать, пока не появятся публичные сертификаты ML-DSA. Инвентаризация, обновление библиотек и автоматизация работы с сертификатами нужны в любом случае, и они займут больше времени, чем ожидание.
• Понимать «устаревший после 2030 года» как «разрешённый до 2035 года». Данные, которые вы зашифруете в 2029 году с классическим обменом ключами, уязвимы весь срок, пока должна сохраняться их конфиденциальность. Сроки установлены ради соответствия требованиям, а не ради безопасности.

Чек-лист на остаток 2026 года

1. Просканируйте с OpenSSL 3.5 каждый публичный и внутренний TLS-эндпоинт и запишите группу, алгоритм сертификата и версию библиотеки.
2. Обновите TLS-библиотеки в базовых образах. Уберите жёстко заданные списки групп. Просканируйте снова.
3. Проверьте гибрид через каждое промежуточное устройство на пути, включая участок от пограничного узла до исходного сервера.
4. Обновите SSH-серверы до OpenSSH 9.9 или новее ради ML-KEM (9.0 и новее уже предлагают гибрид sntrup761), а также сетевые устройства, для которых есть подходящая прошивка.
5. Составьте список всех долгоживущих ключей подписи и якорей доверия с их сроками действия и алгоритмами, которые поддерживает соответствующий HSM.
6. Разверните тестовый CA с ML-DSA и выпустите сертификаты для одного внутреннего сервиса.
7. Автоматизируйте выпуск и ротацию сертификатов везде, где это всё ещё делается вручную.
8. Письменно запросите у поставщиков сроки поддержки ML-KEM и ML-DSA.

Источники

• NIST IR 8547 (первый публичный проект), «Переход на стандарты постквантовой криптографии» (ноябрь 2024 года), таблицы 2–4.
• NSA, Объявление о Commercial National Security Algorithm Suite 2.0 (CSA PP-22-1338, сентябрь 2022 года): алгоритмы и график перехода.
• Скоординированная дорожная карта перехода на постквантовую криптографию, рабочая группа ЕС по PQC (EU PQC Workstream), версия 1.1, 11 июня 2025 года.
• NCSC, Сроки миграции на постквантовую криптографию (март 2025 года).
• FIPS 203, FIPS 204, FIPS 205, SP 800-208.
• OpenSSH, Постквантовая криптография, и примечания к выпускам OpenSSH 9.0, 9.9, 10.0 и 10.1.
• OpenSSL, стратегия выпусков (3.5 LTS до 2030-04-08). Примечания к выпуску Go 1.24, JEP 527.
• Google Security Blog, Развиваем надёжный и эффективный квантово-устойчивый HTTPS (февраль 2026 года).

Сканирование выполнено 20 октября 2026 года в node:24.22.0-trixie (OpenSSL 3.5.7, OpenSSH 10.0p2).