В апреле 2025-го Kubernetes v1.33 молча включил гибридный постквантовый обмен ключами X25519MLKEM768 для всех TLS-соединений - просто за счёт перехода на Go 1.24. Ни отдельного KEP, ни пресс-релиза. Просто обновили рантайм - и вся кластерная коммуникация поехала на постквантовых хендшейках. Chrome, Firefox, Cloudflare, Akamai - все уже в production с гибридными постквантовыми хендшейками. Миграция TLS на постквантовую криптографию перестала быть задачей "на потом": она происходит прямо сейчас. Ниже - чеклист для тех, кому нужно возглавить этот процесс, а не обнаружить его постфактум, разгребая алерты от middlebox'ов.
Harvest Now, Decrypt Later: почему миграция на постквантовые алгоритмы шифрования начинается сейчас
Главный аргумент против "подождём, пока квантовый компьютер появится" - атака Harvest Now, Decrypt Later (HNDL). Противник перехватывает зашифрованный трафик - через Network Sniffing (T1040, Credential Access / Discovery) или Adversary-in-the-Middle (T1557, Credential Access / Collection) - и складывает на хранение. Когда криптографически релевантный квантовый компьютер (CRQC) появится, весь перехваченный трафик расшифровывается ретроактивно за часы. Годы перехвата - часы расшифровки.Это не гипотетика. NSA, CISA и NIST явно предупреждают: государственные акторы уже эксфильтруют шифрованные данные в расчёте на квантовую дешифровку. NIST в отчёте о переходе на PQC обозначил жёсткие рамки: системы с классической криптографией - deprecated после 2030, полный вывод из эксплуатации после 2035. NSA в рамках CNSA 2.0 устанавливает поэтапные дедлайны: для software/firmware signing и web TLS - PQC обязателен с 2025 года, для традиционных сетевых систем - с 2026, для операционных систем - с 2027, полная миграция национальных систем безопасности - к 2033 году. По ряду экспертных оценок, CRQC может появиться к 2030 году. Cloudflare в 2024-м сдвинул внутренний дедлайн миграции с 2035 на 2029 - шесть лет одним решением, это говорит о многом.
Для организаций, обрабатывающих данные с горизонтом конфиденциальности более 5–7 лет - финансовые транзакции, медицинские записи, гостайна - HNDL уже работает как текущий операционный риск. Квантовая угроза касается именно асимметричной криптографии. Симметричные алгоритмы (AES-256) остаются устойчивыми: алгоритм Гровера даёт лишь квадратичное ускорение, снижая эффективную стойкость AES-256 до AES-128, что по-прежнему вычислительно неприступно. Мигрировать нужно конкретно RSA, ECDSA, ECDH, DHE - всё, что стоит за TLS handshake, цифровыми подписями и цепочками сертификатов.
Отсюда чёткая приоритизация:
- Обмен ключами (KEM) - первым. Если key establishment скомпрометирован через HNDL, вся сессия вскрывается вместе с симметрично зашифрованными данными. Угроза ретроактивная - то, что перехвачено сегодня, расшифруется завтра.
- Цифровые подписи - вторым. Подпись должна быть безопасна в момент верификации. Противник не может задним числом подделать подпись, уже проверенную классическим алгоритмом. Мигрировать нужно до появления CRQC, но без ретроактивного давления HNDL.
Российский контекст квантовой угрозы PKI инфраструктуре
В России ТК-26 Росстандарта разрабатывает национальные постквантовые стандарты. По данным TAdviser, уже выпущены методические материалы по алгоритмам "Гиперикум", "Облепиха" и "Земляника", доступна библиотека PQC SDK. Компании QApp и "С-Терра" в 2025 году завершили пилот первого отечественного квантово-устойчивого TLS-шлюза. НСПК, Московская биржа и Газпромбанк провели пилотные проекты с постквантовой защитой финансовых транзакций - включая квантово-устойчивые платежи по Bluetooth. Российский PQC-стек движется параллельно с NIST, но для организаций, работающих с западным стеком протоколов, NIST-стандарты применимы уже сейчас.NIST постквантовые стандарты: ML-KEM, ML-DSA, SLH-DSA для миграции PKI
13–14 августа 2024 года NIST финализировал первые три постквантовых стандарта. Прямая рекомендация из руководства: "There is no need to wait for future standards. Go ahead and start using these three.""Нет нужды ждать будущие стандарты. Начинаем и запускам использование этих трёх." Яснее не скажешь.
| Стандарт | Назначение | Заменяет | Размер ключа / подписи | Когда использовать |
|---|---|---|---|---|
| ML-KEM (FIPS 203) | Обмен ключами | RSA key exchange, ECDH | Публичный ключ ML-KEM-768: ~1.2 КБ | TLS handshake, VPN, key establishment |
| ML-DSA (FIPS 204) | Цифровые подписи | ECDSA, RSA signatures | Подпись ML-DSA-65: ~3.3 КБ | Сертификаты X.509, JWT, code signing |
| SLH-DSA (FIPS 205) | Подписи (hash-based) | Резерв к ML-DSA | 8-49 КБ | Консервативный fallback |
Для большинства инфраструктурных команд точка входа - ML-KEM-768 для обмена ключами (эквивалент AES-192 по уровню безопасности) и ML-DSA-65 для подписей. ML-KEM-512 - минимальный вариант (AES-128), ML-KEM-1024 - для сред с максимальными требованиями. ML-DSA-87 - повышенный уровень для долгосрочных подписей.
Зачем нужен SLH-DSA при наличии ML-DSA
ML-KEM и ML-DSA построены на решёточной криптографии (module lattice problems). Если в этом классе задач обнаружится фундаментальная слабость - оба стандарта станут уязвимы одновременно. Прецедент есть, и он показательный: алгоритм SIKE прошёл до финального раунда стандартизации NIST, прежде чем исследователи показали, что он полностью взламывается классическим компьютером. Не квантовым - обычным. SLH-DSA основан на хеш-функциях - математически независимых от решёток - и от такой уязвимости не пострадает. Отсюда требование к архитектуре: crypto agility - способность переключить алгоритм без переделки инфраструктуры.В разработке также FN-DSA (draft FIPS 206, бывший FALCON) - компактные подписи для bandwidth-constrained сред.
Криптоинвентаризация: постквантовый PKI чеклист с командами
Прежде чем что-то мигрировать - инвентаризация всей криптографии в контуре. Без неё вы не знаете, что у вас есть. Ниже чеклист, пригодный для включения в отчёт или передачи инфраструктурной команде.
Требования к окружению
- OpenSSL 3.2+ для базового сканирования (вывод negotiated group требует 3.2+); 3.5+ для проверки PQC-совместимости
- sslyze 6.0+ (Python 3.9+, установка через
pip install sslyze) - Сетевой доступ к внутренним и внешним TLS-эндпоинтам из сети мониторинга
- Для PQC-тестов: Go 1.24+ или OpenSSL 3.5 с OQS-provider
Bash:
# Cipher suite и группа обмена ключами для одного хоста
openssl s_client -connect target:443 -brief < /dev/null 2>&1 \
| grep -E "Protocol|Ciphersuite|group"
# Массовый скан с выводом в JSON для парсинга
sslyze --regular --json_out=inventory.json hosts.txtШаг 2. Инвентаризация сертификатов и цепочек доверия.
Bash:
# Алгоритм подписи конкретного сертификата
openssl x509 -in cert.pem -noout -text | grep "Signature Algorithm"
# Извлечь алгоритмы подписи всех сертификатов в системном trust store
awk '/BEGIN/{n++} {print > ("/tmp/cert_" n ".pem")}' \
/etc/ssl/certs/ca-certificates.crt && \
for f in /tmp/cert_*.pem; do \
openssl x509 -in "$f" -noout -subject 2>/dev/null; \
openssl x509 -in "$f" -noout -text 2>/dev/null | grep -m1 'Signature Algorithm'; \
done; rm -f /tmp/cert_*.pemkeytool -list -v), конфиги nginx/HAProxy, корпоративные CA - Vault, EJBCA, ADCS. Забытый keystore - типичная точка, где миграция буксует через полгода.Шаг 3. Аудит зависимостей. Проверяйте не только свой код:
- TLS-библиотека: OpenSSL 3.5+ - нативная поддержка ML-KEM; BoringSSL (Chrome, Android) - поддержка есть; LibreSSL - отстаёт
- Go: 1.24+ - X25519MLKEM768 по умолчанию; 1.23 - несовместимый draft X25519Kyber768Draft00 (об этом ниже - ловушка неприятная)
- JWT: большинство библиотек не поддерживают ML-DSA - зафиксируйте этот gap с оценкой сроков
- CA-софт: step-ca и cfssl работают над PQC-поддержкой; Let's Encrypt анонсировал планы, PQC-сертификаты ещё не выпускает
- Облачный TLS: AWS, Google Cloud, Cloudflare - гибридный PQC key exchange доступен; Akamai - limited availability с сентября 2025, дефолт запланирован на февраль 2026
Шаг 5. Приоритизация по lifetime ключей. Составьте таблицу: система, криптографический примитив, срок жизни ключа, чувствительность данных. Длинноживущие ключи - корневые CA-сертификаты, ключи code signing, SSH host keys - первые кандидаты на миграцию. Их компрометация даёт максимальный импакт: атакующий имперсонирует ваш CA, сервер обновлений или API-шлюз (Private Keys, T1552.004; Install Root Certificate, T1553.004).
Гибридная криптография TLS 1.3: первый шаг к квантово-устойчивым алгоритмам
Гибридный режим - одновременное использование классического (X25519) и постквантового (ML-KEM) алгоритма в одном TLS handshake. Сессионный ключ безопасен, пока хотя бы один из двух алгоритмов не взломан. Это рекомендуемая точка входа в постквантовый переход сертификатов и ключей: если PQC-алгоритм окажется уязвим (как SIKE), классическая криптография сохранит защиту. Страховка, встроенная в протокол.Состояние production-развёртываний гибридного X25519MLKEM768 на середину 2025 года:
- Cloudflare - значительная доля пользовательского трафика защищена гибридным PQC (точные метрики на Cloudflare Radar)
- Chrome 131 (ноябрь 2024), Firefox 135 (февраль 2025) - нативная поддержка
- OpenSSL 3.5 (апрель 2025) - нативная реализация ML-KEM
- Go 1.24 (февраль 2025) - включено по умолчанию при незаданном
Config.CurvePreferences - Akamai - hybrid ML-KEM + X25519 c сентября 2025, планы на дефолт в феврале 2026
- Apple - внедряет X25519MLKEM768 в 26-й версии своих ОС
Ограничения: размер ClientHello и middlebox
Вот тут начинается самое интересное. Hybrid key_share X25519MLKEM768 в ClientHello добавляет ~1216 байт payload (1184 для ML-KEM-768 + 32 для X25519). Вместе с другими расширениями ClientHello вылезает за пределы типичного TCP MSS (1460 байт при Ethernet MTU 1500), и происходит фрагментация на несколько сегментов. А middlebox-устройства - WAF, балансировщики, DPI-системы - нередко ожидают однопакетный ClientHello и тихо дропают или ломают фрагментированные сообщения. Перед включением в production:- Протестируйте обработку фрагментированного ClientHello на каждом middlebox в цепочке
- Проверьте совместимость QUIC amplification protection с увеличенными пакетами
- TLS 1.3 - обязательное предусловие для PQC-миграции: TLS 1.2 получил оценку 0 по PQC-готовности, постквантовые алгоритмы в него добавляться не будут. Сервисы на TLS 1.2 нужно мигрировать на TLS 1.3 до начала PQC-перехода
Ловушка несовместимости версий Go в Kubernetes
Kubernetes v1.32 (Go 1.23) использовал draft-версию X25519Kyber768Draft00. Kubernetes v1.33 (Go 1.24) - финальный X25519MLKEM768. Эти алгоритмы несовместимы: при рассогласовании версий (kubectl v1.33 подключается к API-серверу v1.32) PQC KEM не согласовывается, и соединение молча откатывается к классическому X25519. Постквантовая защита теряется без единого алерта.На бумаге это выглядит как мелочь - ну, откатился на классику, подумаешь. На практике - вы уверены, что у вас PQC, а его нет. Именно поэтому PQC-миграция требует контролируемого тестирования и мониторинга, а не пассивного ожидания.
Миграция PKI на постквантовую криптографию: самый сложный участок
По оценке Keyfactor, миграция PKI - наиболее разрушительная часть постквантового перехода. Каскадный эффект от увеличения размеров подписей бьёт по всей цепочке:- ML-DSA-65 - ~3.3 КБ на подпись (ECDSA - десятки байт)
- Стандартная цепочка X.509: 2–3 сертификата, каждый с подписью
- TLS handshake с полной PQC-цепочкой вырастает на порядок
Корневые сертификаты - отдельная головная боль. Они встроены в trust store операционных систем и устройств, живут десятилетиями. Замена корневого CA на постквантовый - процесс с горизонтом в годы. Механизм ротации корневого сертификата нужно отработать до начала миграции, а не во время неё. Кто менял корневой CA на ходу - тот знает цену этой ошибки.
Crypto agility как архитектурный принцип. Все сервисы должны уметь принимать сертификаты с разными алгоритмами подписи (RSA, ECDSA, ML-DSA). CA должен выпускать PQC-сертификаты параллельно с классическими. Без криптографической гибкости каждая следующая криптографическая миграция начинается с нуля - а история показывает, что миграции неизбежны: SSL -> TLS 1.0 -> 1.3, SHA-1 -> SHA-256, RSA-1024 -> RSA-2048, и вот теперь - RSA/ECC -> ML-KEM/ML-DSA.
Detection: SIEM-правила для мониторинга постквантового перехода
Заключение
Самая частая ошибка, которую я наблюдаю в проектах по криптографической миграции: команды начинают с выбора алгоритмов, а не с инвентаризации. Через полгода выясняется, что три критичных сервиса работают на HSM с прошивкой 2018 года, которая не обновляется, - и вся красивая архитектура с ML-KEM разбивается об аппаратное ограничение. Миграция с RSA на ECC заняла больше десяти лет, и многие организации её так и не завершили. Постквантовый переход будет сложнее: больше размеры ключей, непривычная математика, необходимость гибридного режима на годы переходного периода.Через два-три года организации разделятся на две категории: те, кто начал криптоинвентаризацию в 2025-м и распределил бюджет на замену HSM, и те, кто будет спешно менять оборудование под давлением регуляторов в 2028-м с трёхкратным бюджетом и сорванными SLA. Если ваша организация обрабатывает данные с горизонтом конфиденциальности 10+ лет, окно для начала закрывается - HNDL работает против вас каждый день, пока обмен ключами идёт по классическим алгоритмам. Если интересно, как другие команды строят мониторинг PQC-даунгрейдов и детектят откат хендшейков на классику - на codeby.net в треде по криптографическому мониторингу коллеги делятся Sigma-правилами и конфигами под конкретные SIEM-стеки.
Последнее редактирование модератором:
