13 августа 2024 года NIST опубликовал три финальных стандарта постквантовой криптографии - FIPS 203, 204 и 205. Восемь лет конкурса, десятки алгоритмов-кандидатов, и вот - результат. Но для security-инженера за красивой датой стоит конкретный дедлайн: согласно таймлайну NIST IR 8547, алгоритмы RSA, ECDH и ECDSA будут deprecated в федеральных стандартах к 2035 году. Не "когда-нибудь" - с опубликованным графиком. А если в вашей инфраструктуре прямо сейчас летает трафик, зашифрованный RSA-2048 или ECDH P-256, он уже может быть целью harvest now, decrypt later. И вот тут начинается самое интересное.
Harvest now, decrypt later: квантовая угроза как актуальный TTP
HNDL - не абстрактная модель угрозы из академической статьи, а конкретная тактика, которую атрибутируют группировкам с государственным ресурсом. Механика прямолинейна до неприличия: атакующий перехватывает зашифрованный трафик прямо сейчас - через Network Sniffing (T1040) или Adversary-in-the-Middle (T1557) - и складывает в хранилище до момента, когда криптографически релевантный квантовый компьютер (CRQC) позволит расшифровать всё алгоритмом Шора. Для HNDL не нужен квантовый компьютер сегодня. Достаточно сетевого доступа и дешёвого хранилища.По ряду оценок, значительная часть глобальных финансовых активов привязана к криптосистемам, уязвимым для квантовых атак. Финансовые сети, каналы связи государственных органов, медицинские данные - всё, что защищено RSA или ECDH.
NSA в CNSA 2.0 (сентябрь 2022 года) установила жёсткие сроки: новые системы нацбезопасности используют постквантовые алгоритмы немедленно, legacy-инфраструктура - поэтапно: software/firmware signing к 2025, networking к 2026, ОС к 2027, полный переход NSS к 2033 (по данным CNSA 2.0 guidance). NIST подтвердил в IR 8547: квантово-уязвимые алгоритмы будут полностью удалены из федеральных стандартов к 2035 году, системы с высоким риском переходят значительно раньше.
Для blue team всё сводится к одному вопросу: какие данные в вашей сети сохраняют ценность через 10–15 лет? Медицинские записи, финансовые транзакции, интеллектуальная собственность, гостайна? Если да - миграция на постквантовую криптографию нужна сейчас, а не когда появится CRQC.
Три стандарта FIPS: какой PQC-алгоритм для какой задачи
NIST выпустил три стандарта, и это не три альтернативы одной функции - каждый закрывает свою криптографическую задачу. Миграционная программа, которая их путает, построена на ошибке. FIPS 203, 204, 205 - фундамент корпоративной миграции на квантово-устойчивую криптографию.
FIPS 203 - ML-KEM: обмен ключами вместо RSA и ECDH
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) - стандартное название алгоритма, ранее известного как CRYSTALS-Kyber. "Kyber" - имя конкурсной заявки, и в compliance-документации оно уже ничего не значит. В procurement-спецификациях следует использовать именно ML-KEM: неоднозначность терминологии создаёт реальные риски в policy-контекстах.Сразу уточню: ML-KEM - механизм инкапсуляции ключей, не алгоритм шифрования общего назначения. Он создаёт общий симметричный секрет между двумя сторонами через недоверенный канал, не передавая сам ключ. Контексты: TLS 1.3 key exchange, SSH key agreement, IPsec IKEv2 - везде, где сейчас работает RSA или ECDH для key establishment.
Математическая основа - задача Module Learning With Errors (MLWE), структурированный вариант LWE. Для MLWE не известен полиномиальный алгоритм ни на классическом, ни на квантовом компьютере - на этом допущении стоит весь стандарт.
| Набор параметров | Категория NIST | Классический эквивалент |
|---|---|---|
| ML-KEM-512 | 1 | AES-128 |
| ML-KEM-768 | 3 | AES-192 |
| ML-KEM-1024 | 5 | AES-256 |
Для большинства корпоративных деплойментов ML-KEM-768 - разумная отправная точка. CNSA 2.0 требует Category 5 (ML-KEM-1024) для систем нацбезопасности. UK NCSC (2024) рекомендует ML-KEM-768 или выше как baseline.
В финальных стандартах NIST по сравнению с драфтами 2023 года добавлены механизмы domain separation - разделение между параметрами разных уровней безопасности, чтобы нельзя было случайно (или намеренно) подсунуть ключ от одного уровня в контекст другого (по данным PQShield). Не косметика - стандартная практика hardening криптореализаций.
А теперь цифры, от которых начинает дёргаться глаз. Публичный ключ ML-KEM-768 занимает 1184 байта, шифротекст - 1088 байт. X25519 key share в TLS - 32 байта. Рост на порядки. Держите это в голове, когда дойдём до раздела про TLS handshake.
FIPS 204 - ML-DSA: основная постквантовая цифровая подпись
ML-DSA (Module-Lattice-Based Digital Signature Algorithm, ранее CRYSTALS-Dilithium) - основной стандарт цифровой подписи для корпоративных применений: подпись сертификатов CA, code signing, document signing, аутентификация. Заменяет RSA-PSS, ECDSA, EdDSA.Математическая основа - та же задача MLWE. Осознанное архитектурное решение: миграционная программа строится вокруг одного семейства криптографических допущений, что упрощает модель рисков. Обратная сторона медали: прорыв в криптоанализе MLWE ударит одновременно по ML-KEM и ML-DSA. Об этом - в финале.
| Набор параметров | Категория NIST |
|---|---|
| ML-DSA-44 | 2 |
| ML-DSA-65 | 3 |
| ML-DSA-87 | 5 |
ML-DSA-65 - корпоративный default. ML-DSA-87 (Category 5) обязателен по CNSA 2.0 для нацбезопасности.
Критическая цифра: подпись ML-DSA-65 занимает 3309 байт (FIPS 204, Table 1). Подпись ECDSA P-256 - 64 байта в raw-формате (~71 байт в DER-кодировке X.509). Разница в ~46–51 раз в зависимости от формата. Это прямо влияет на размер TLS certificate chains с промежуточными CA, пропускную способность при массовой верификации подписей, объём signed-артефактов в CI/CD. Не абстрактная проблема - инженерная реальность.
FIPS 205 - SLH-DSA: постквантовый стандарт на хэш-подписях
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, ранее SPHINCS+) - альтернативный механизм цифровой подписи. Принципиальное отличие: безопасность основана исключительно на свойствах хэш-функций (SHA-256, SHA-512, SHAKE), а не на решёточной криптографии. Если хэш-функция коллизионно-устойчива - подписи SLH-DSA безопасны. Никакого допущения MLWE.Зачем NIST стандартизировал SLH-DSA параллельно с ML-DSA? Не как замену, а для алгоритмической диверсификации. Если в будущем обнаружится теоретическая слабость в MLWE (чего пока не произошло, но это релевантный failure mode для планирования), ML-DSA-развёртывания пострадают, SLH-DSA - нет. Страховка, по сути.
Компромисс - размер подписей. Стандарт определяет 12 наборов параметров с двумя режимами:
s (small - компактнее подпись, медленнее подписание) и f (fast - быстрее подписание, крупнее подпись).| Набор параметров | Размер подписи | Категория NIST |
|---|---|---|
| SLH-DSA-SHA2-128s | 7 856 Б | 1 |
| SLH-DSA-SHA2-256s | 29 792 Б | 5 |
SLH-DSA-SHA2-128s - уже в 2,4 раза крупнее ML-DSA-65. SLH-DSA-SHA2-256s (мандат CNSA 2.0) с подписью ~30 КБ - не для throughput-constrained приложений, мягко говоря.
Где использовать: корневые CA, долгосрочные trust anchors, подпись кода в software supply chain - контексты, где размер подписи не ограничивающий фактор, а диверсификация от решёточных задач в приоритете.
Где не использовать: TLS certificate chains с высокой нагрузкой, массовая подпись документов, real-time аутентификация. В большинстве миграционных проектов ошибки деплоя возникали именно на этом разграничении - путали "запасной" алгоритм с "основным".
Размеры артефактов: влияние на TLS и PKI при миграции на постквантовую криптографию
Для security-инженера, управляющего PKI-инфраструктурой, главный вопрос - не "какой алгоритм выбрать", а "что сломается при переходе и как это мониторить в SIEM".
Сводная таблица размеров на уровне безопасности NIST Category 3:
| Артефакт | Классика | PQC | Рост |
|---|---|---|---|
| Key share (key exchange) | 32 Б (X25519) | 1 088 Б (ML-KEM-768 ct) | x34 |
| Подпись (signature) | 64 Б (ECDSA P-256) | 3 309 Б (ML-DSA-65) | x51 |
| Подпись (hash-based, backup) | - | 7 856 Б (SLH-DSA-128s) | - |
Теперь к практическим последствиям - и тут начинается боль.
TLS handshake вырастает ощутимо. ML-KEM-768 для key exchange + ML-DSA-65 для подписи сертификатов: certificate chain с двумя промежуточными CA добавляет десятки килобайт к handshake. На широкополосных каналах - приемлемо. На IoT, мобильных сетях с ограниченным MTU, VPN-туннелях на edge-устройствах - точка отказа.
Certificate chains нужно тестировать под нагрузкой до миграции, не после. Каждый промежуточный сертификат с ML-DSA-65 подписью добавляет ~3,3 КБ. Три уровня - +10 КБ только подписей.
Гибридный режим удваивает overhead. В переходный период рекомендуется hybrid deployment: ML-KEM-768 параллельно с X25519 - безопасность сохраняется, даже если один алгоритм окажется уязвим. Такой подход уже используют Signal, Apple, Google и Zoom (по данным Kaspersky). Гибридные конструкции не описаны в FIPS 203–205 - они определены в NIST IR 8547 (Initial Public Draft, 2024), IETF draft-ietf-tls-hybrid-design. Для европейского рынка - ETSI TS 103 744.
Что стандарты не покрывают. Три FIPS определяют алгоритмы. Архитектуру миграции определяют transition-документы. Stateful хэш-подписи (XMSS, LMS) - отдельный стандарт NIST SP 800-208 (октябрь 2020), не замена FIPS 205. Путать их - отдельный класс ошибок.
Чеклист миграции на постквантовую криптографию для security-инженера
Конкретные шаги, которые можно включить в roadmap или передать в отчёт по аудиту. Без воды - только действия.- Криптографический инвентарь. Аудит всех точек использования асимметричной криптографии: TLS-терминаторы, VPN-шлюзы (IPsec IKEv2), SSH-серверы, PKI-иерархия (root CA, intermediate, leaf), code signing, document signing. Для каждой точки фиксируете: алгоритм, размер ключа, срок жизни данных, которые этот ключ защищает. Скучно? Да. Необходимо? Абсолютно.
- Классификация по sensitivity lifetime. Данные с горизонтом конфиденциальности 10+ лет (медицина, финансы, гостайна) - приоритет миграции. Ephemeral keys и сессионные токены - мигрируете позже.
- Проверка PQC-поддержки в криптостеке. OpenSSL 3.x с oqs-provider (liboqs) поддерживает ML-KEM и ML-DSA. BoringSSL (Chrome, Android) поддерживает ML-KEM. Проверить состояние вашего стека:
Bash:
# OpenSSL 3.x с подключённым oqs-provider
openssl list -kem-algorithms 2>/dev/null | grep -i ml-kem
# Пустой вывод = PQC не поддерживается в текущей конфигурации- Пилотный hybrid deployment. Начинаете с TLS 1.3 key exchange: ML-KEM-768 + X25519 в hybrid mode. Минимально инвазивное изменение - затрагивает key agreement, не трогает подписи в сертификатах. Хорошая точка входа.
- Нагрузочное тестирование certificate chain. До перевода CA на ML-DSA - тестирование handshake на реальных клиентских профилях: мобильные, IoT, legacy. Зафиксировать baseline RTT и сравнить с PQC-вариантом. Если RTT вырос в два раза - у вас проблема, и лучше узнать о ней в лабе, а не на проде.
- SLH-DSA для root CA. При создании нового PKI или ротации root CA - SLH-DSA для корневого сертификата (подписывается редко, размер не критичен), ML-DSA для промежуточных и leaf.
- Выравнивание по таймлайну. CNSA 2.0: немедленно для новых систем, 2030–2033 для legacy. NIST IR 8547: deprecation к 2035. Внутренний дедлайн ставьте с запасом 2–4 года на PKI-миграцию корпоративного масштаба. Кто делал ротацию корневого CA в крупной организации - знает, почему запас нужен.
Detection: что мониторить в SIEM при постквантовом переходе PKI
Этот подход позволяет наращивать coverage поэтапно: начать с серверов в scope миграции, расширять по мере rollout.
По опыту работы с PKI-инфраструктурами, самая частая ошибка при обсуждении постквантового перехода - фокус на выборе конкретного алгоритма вместо фокуса на crypto-agility. ML-KEM-768 или ML-KEM-1024, ML-DSA-65 или ML-DSA-87 - решение, которое занимает день. А вот ответ на вопрос "может ли ваша инфраструктура заменить криптоалгоритм за неделю, а не за два года?" - архитектурная проблема, определяющая устойчивость на десятилетия. Если MLWE окажется слабее, чем предполагалось (а у ML-KEM и ML-DSA общая математическая основа - помните?), организация с crypto-agile архитектурой переключится на SLH-DSA за спринт. Без неё - за годы. Таймлайн до 2035 кажется длинным, но практика показывает: большинство инфраструктур переходят на новый криптостандарт только когда старый уже deprecated. Тот, кто начинает инвентаризацию криптозависимостей сегодня, получает не просто compliance advantage - он получает способность реагировать на криптографические инциденты, которых ещё не было, но которые этот переход неизбежно принесёт. Если строите PQC-migration playbook и не хотите изобретать шаблон с нуля - на codeby.net коллеги обсуждают подходы к криптоинвентаризации и приоритизации под конкретные инфраструктуры.
Последнее редактирование модератором:
