Постквантовые SSH и TLS

Постквантовая криптография десять лет была темой конференций, а потом тихо стала значением по умолчанию на вашем ноутбуке. Если у вас OpenSSH 10 и браузер последних двух лет, бо́льшая часть вашего трафика уже защищена от квантового противника — просто вам об этом не сообщили. Остаётся работа узкая, невыигрышная и очень конкретная: найти соединения, которые остались позади. Эта статья о том, как сделать это на реальной инфраструктуре: что проверить, что изменить, как потом убедиться в результате и какую часть задачи сейчас лучше сознательно не трогать.

Управляемой всю эту тему делает одно разделение. Криптография защищает соединения двумя способами: согласование ключей определяет секрет, которым шифруется сессия, а подписи доказывают, с кем вы разговариваете. Квантовый компьютер ломает и то, и другое. Но срочным сегодня является только одно, и именно смешение этих двух вещей объясняет, почему столько постквантовых программ застревает в таблице. Всё дальнейшее следует из этого различия.

Где постквантовая криптография находится на самом деле в 2026 году

Согласование ключей сделано. Не запланировано и не в пилоте — выпущено, поставлено по умолчанию и работает. OpenSSH предлагает постквантовое согласование ключей с версии 9.0 от апреля 2022 года, а с OpenSSH 10.0 от апреля 2025-го гибрид mlkem768x25519-sha256 является алгоритмом по умолчанию. OpenSSL 3.5.0, вышедший днём ранее, изменил список поддерживаемых групп TLS по умолчанию так, чтобы включать и предпочитать гибридные постквантовые группы, и теперь предлагает X25519MLKEM768 в качестве keyshare по умолчанию. Если вы за последний год обновляли любой из этих пакетов, вы включили всё это, ничего не делая.^{[ssh100][ossl35]}

Измерения подтверждают картину. Cloudflare с 2023 года публикует данные о распространении постквантового согласования ключей, и кривая примерно за два года выросла от погрешности округления до большинства человеческого веб-трафика. Смотрите живую цифру, а не доверяйте статье — в том числе этой: важен не точный процент, а форма кривой. Именно она говорит, что отстающие теперь конечное перечислимое множество, а не весь интернет.^{[cfpq][cfradar]}

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

Собрать сейчас, расшифровать потом — и что эта атака не покрывает

Почему согласование ключей срочно, а подписи — нет, сводится к одной асимметрии, и OpenSSH формулирует её яснее, чем большинство вендорских материалов:^[pq]

Вся приватность SSH-соединения зависит от криптографического согласования ключей. Если атакующий сумеет его сломать, он сможет расшифровать и прочитать сессию целиком. Ему не нужно проводить атаку в реальном времени: он может собирать зашифрованные SSH-сессии сейчас и расшифровать их позже, получив доступ к квантовому компьютеру.^[pq]

Это собрать сейчас, расшифровать потом — ретроактивная атака. Сессия, перехваченная сегодня на канале с классическим обменом ключами, — это постоянное обязательство: она лежит в архиве, пока не появится криптографически значимый квантовый компьютер, и тогда открывается. Ничто из сделанного вами в 2032 году не починит сессию, записанную в 2026-м. У подписей аналога нет: подделав подпись задним числом, нельзя вернуться и выдать себя за кого-то в уже состоявшемся разговоре. Отсюда чистое правило приоритизации:

• Долгоживущие конфиденциальные данные по долгоживущему каналу. Репликация БД через WAN, передача резервных копий, VPN-туннели между площадками, SSH-сессии, куда вы вставляете учётные данные. Чинить в первую очередь: полезная нагрузка сохраняет ценность десятилетие и дольше.
• Трафик, идущий по недоверенному пути. Всё, что покидает вашу сеть, а в серьёзной модели угроз — и всё, что пересекает магистраль облачного провайдера. Перехват дёшев для того, у кого есть позиция; хранение ещё дешевле.
• Связи «машина — машина», куда никто не логинится. Именно их пропускает аудит, потому что нет человека, который увидел бы предупреждение. Service mesh, очереди сообщений, каналы репликации, агенты мониторинга.
• Короткоживущий, малоценный, чисто внутренний трафик. Health check между двумя подами на одном узле не стоит тикета на миграцию. Запишите это, чтобы исключение было решением, а не недосмотром.

Оценки того, когда появится криптографически значимый квантовый компьютер, расходятся от пяти до двадцати лет, и многие наблюдатели ждут середины 2030-х. Вам не нужно иметь мнение об этой цифре. Вам нужно знать, останутся ли данные, которые вы передаёте сегодня, чувствительными к тому моменту, — и для большинства инфраструктур честный ответ «да».^[pq]

Чиним SSH

SSH — лёгкая победа и правильная точка старта, потому что сложную часть OpenSSH уже сделал за вас. Ни плагина, ни провайдера для установки, ни экспериментальной ветки. Есть номер версии и строка конфигурации, и проект публикует и то, и другое.^{[ssh100][pq][ssh105][sshrel]}

В этой таблице спрятаны две ловушки. Первая — имя: короткая форма sntrup761x25519-sha512 существует только с 9.9, поэтому на всём, что старше, нужно писать вариант с @openssh.com, а sshd отказывается стартовать при незнакомом имени. Вторая коварнее. Присутствовать в списке по умолчанию и быть выбранным из него — не одно и то же: в OpenSSH 8.9 постквантовый алгоритм действительно входит в стандартный KexAlgorithms, но стоит там шестым, ниже curve25519-sha256. В результате любой современный клиент согласует с таким сервером классический обмен, а сервер при этом совершенно честно сообщает о поддержке постквантовой криптографии. Именно поэтому статья настойчиво требует читать согласованный результат, а не список поддерживаемого.^{[ssh85][ssh99][ntru]}

Шаг 1: выяснить, что вы согласуете на самом деле

Прежде чем что-то менять, измерьте. Различие, на котором спотыкаются почти все, — между поддерживается и согласовано: сервер может поддерживать ML-KEM и всё равно завершить классический обмен, потому что устаревший клиент попросил его, а список предпочтений сервера это допустил. Только согласованный алгоритм говорит, была ли конкретная сессия реально защищена.

# 1. Your client. Anything older than 8.5 has no post-quantum key agreement
#    at all; 8.5 through 9.8 have it only under the @openssh.com vendor name.
ssh -V
# OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026

# 2. The remote server's software version, straight from the protocol banner.
ssh -v server.example.com exit 2>&1 | grep 'remote software version'
# debug1: Remote protocol version 2.0, remote software version OpenSSH_10.3

# 3. Which key agreement algorithms your local build even supports.
ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256
# sntrup761x25519-sha512

# 4. Supported is not preferred. On OpenSSH 8.9, for example, the PQ algorithm
#    is in the default list but sixth in it, so it is offered and never chosen:
ssh -G server.example.com | grep -i '^kexalgorithms'
# kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
# ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,...
#                                       ^ present, but nothing will ever pick it

# 5. The only answer that matters: what did THIS connection actually agree on?
#    Everything above is capability; this line is the negotiated result.
ssh -v server.example.com exit 2>&1 | sed -n 's/.*kex: algorithm: /negotiated: /p'
# negotiated: mlkem768x25519-sha256

Как только вы умеете читать эту строку для одного хоста, вы умеете читать её для всех. В OpenSSH 10.1 появилось клиентское предупреждение, когда соединение согласует непостквантовый обмен: отлично для людей и бесполезно для автоматических связей, из которых состоит основная часть реального парка. Значит, обходите сами:^[ssh101]

#!/usr/bin/env bash
# pq-ssh-sweep.sh - classify every host in hosts.txt by negotiated key agreement.
# Read-only: it opens a connection, runs `exit`, and reads the debug output.
set -uo pipefail

while read -r host; do
  [ -z "$host" ] && continue
  # </dev/null matters: without it ssh swallows the rest of hosts.txt from the
  # loop's stdin and you silently audit only the first host.
  alg=$(ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new \
        -v "$host" exit </dev/null 2>&1 | sed -n 's/.*kex: algorithm: //p' | head -1)
  case "$alg" in
    mlkem*)   printf '%-38s PQ-ML-KEM  %s\n' "$host" "$alg" ;;
    sntrup*)  printf '%-38s PQ-LEGACY  %s\n' "$host" "$alg" ;;
    "")       printf '%-38s UNREACHED  (auth, firewall or timeout)\n' "$host" ;;
    *)        printf '%-38s CLASSICAL  %s\n' "$host" "$alg" ;;
  esac
done < hosts.txt

# PQ-ML-KEM  -> done, nothing to do.
# PQ-LEGACY  -> safe today (sntrup761 is quantum-resistant) but not the NIST
#               standard; schedule the upgrade to OpenSSH 9.9+ anyway.
# CLASSICAL  -> this is your harvest-now-decrypt-later exposure. Fix first.

Шаг 2: аккуратно изменить конфигурацию

Когда обследование на руках, само изменение маленькое. Положите его в drop-in файл вместо правки основного конфига — так правка остаётся находимой, откатываемой и очевидно вашей:^{[sshdcfg][ssh99]}

# /etc/ssh/sshd_config.d/50-post-quantum.conf
# Requires `Include /etc/ssh/sshd_config.d/*.conf` in the main sshd_config,
# which Debian, Ubuntu, RHEL and Fedora already ship. Check with:
#   grep -r '^Include' /etc/ssh/sshd_config

# --- OpenSSH 9.9 and newer ---
# Post-quantum first, classical last. The list is ordered by preference, and
# the two hybrids are the only entries here that resist a quantum adversary.
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org

# --- OpenSSH 9.0 to 9.8: NEITHER name above exists on those builds. ---
# ML-KEM only arrived in 9.9, and until 9.9 the NTRU Prime hybrid existed
# solely under its vendor extension name. sshd refuses to start on an
# unknown algorithm name, so on those versions use exactly this line and
# nothing from the one above:
#   KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
# Confirm which names your build accepts before editing:  ssh -Q kex

# Signatures are NOT the urgent problem (see the article), but this is a good
# moment to drop the algorithms that are weak for classical reasons too.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# --- Validate BEFORE reloading, and keep your current session open. ---
#   sudo sshd -t && sudo systemctl reload ssh   # or sshd, depending on the distro
# Then open a SECOND session and confirm it works before closing the first.

Не пропускайте ритуал проверки. Выполните sshd -t перед перезагрузкой конфигурации, не закрывайте текущую сессию и откройте вторую для подтверждения, прежде чем закрыть первую. Опечатка в KexAlgorithms закрывает вам доступ к хосту, а на машине без консольного доступа это не инцидент, а переустановка.

На стороне клиента можно быть строже: громко падать на собственном ноутбуке допустимо, на общем бастионе — нет. Схема, выдерживающая столкновение с реальностью, — жёсткое значение по умолчанию плюс явные исключения с датой:^[sshcfg]

# ~/.ssh/config - client side
#
# ssh_config is FIRST-OBTAINED-VALUE-WINS, not last. The specific block must
# come BEFORE `Host *`, otherwise the general block wins and the exception
# below is silently dead. This is the single most common mistake in hardened
# client configs, and it fails in the direction you will not notice.

# Exceptions first: the boxes you have not fixed yet. Make each one explicit
# and dated, so it shows up in review instead of quietly becoming permanent.
Host legacy-nas.internal jump-2019.example.com
    # TODO(2026-11-30): appliance firmware pending, ticket OPS-4471
    # Note this REPLACES the list rather than using `+`, which would append to
    # the full compiled-in default and quietly re-enable every modp group.
    KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
    WarnWeakCrypto no-pq-kex

# ...and the hard default for everything else.
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512
    WarnWeakCrypto yes

# Verify the result rather than trusting the file. `ssh -G` prints the
# effective configuration for a given destination, after all matching:
#   ssh -G legacy-nas.internal | grep -i '^kexalgorithms'
#   ssh -G anything-else.example.com | grep -i '^kexalgorithms'

Две детали, которые стоит усвоить. Во-первых, все постквантовые алгоритмы, реализованные в OpenSSH, — гибриды: mlkem768x25519-sha256 выполняет ML-KEM вместе с X25519 и комбинирует оба, поэтому даже если будущий криптоанализ сломает ML-KEM, результат окажется не слабее классического обмена, которым вы пользовались раньше. Проигрышного сценария нет. Во-вторых, если вы на OpenSSH 9.x и обновиться не можете, гибрид NTRU Prime квантово-устойчив и доступен с версии 9.0, но важно имя: до 9.9 он существует только как sntrup761x25519-sha512@openssh.com, а короткая форма будет отвергнута. Это не алгоритм NIST, но он останавливает атаку сбора уже сегодня, а в этом и весь смысл.^[pq]

Чиним TLS

У TLS та же форма, но другой рычаг. Примитивы живут в OpenSSL, а не в вашем веб-сервере: с OpenSSL 3.5 и новее не нужны ни патчи, ни oqs-provider, ни форк nginx. Сначала проверьте библиотеку — именно здесь прячется большинство сюрпризов: дистрибутив вполне может поставлять свежий nginx, слинкованный с OpenSSL, который вообще не умеет ML-KEM.^{[ossl35][tlsdraft][mlkemkex]}

# 1. ML-KEM needs OpenSSL 3.5.0 or newer. No 3.x before 3.5 can do it at all,
#    however recent the rest of the stack looks.
openssl version
# OpenSSL 3.5.7 9 Jun 2026

# 2. Confirm the provider actually exposes the primitives.
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ML-DSA|SLH-DSA'

# 3. What does a live endpoint negotiate when the client offers the hybrid?
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Negotiated TLS1.3 group|Protocol  :|Cipher    :'
# Negotiated TLS1.3 group: X25519MLKEM768

# 4. Control test: the same endpoint must still serve a classical-only client,
#    otherwise you have not hardened it, you have broken it.
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 -tls1_3 </dev/null 2>/dev/null \
  | grep 'Negotiated TLS1.3 group'
# Negotiated TLS1.3 group: X25519

Обратите внимание на контрольный тест на четвёртом шаге. Включение гибридной группы не должно ломать классических клиентов; если сломало — вы неправильно настроили список, а не усилили защиту. Порядок важен, исключительность — нет: гибрид вперёд, классические кривые оставить позади.^[osslgroups]

# Pick the ONE stanza that matches your terminator - this is four different
# config syntaxes in one block, not a file you can paste as-is.

### nginx (built against OpenSSL 3.5+; no patches, no oqs-provider needed)
# ssl_ecdh_curve feeds the TLS supported-groups list. Hybrid first, then the
# classical curves that keep older clients working.
ssl_protocols       TLSv1.3 TLSv1.2;
ssl_ecdh_curve      X25519MLKEM768:X25519:secp256r1;
ssl_prefer_server_ciphers off;

### HAProxy 3.x
ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

### Apache httpd (mod_ssl passes the list straight to OpenSSL)
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

### OpenSSL system-wide default, for everything that reads openssl.cnf
# [openssl_init] -> ssl_conf -> system_default
Groups = X25519MLKEM768:X25519:secp256r1

Конфигурация — по одной строке на сервер, и во всех случаях она питает один и тот же список групп OpenSSL:^{[nginxssl][haproxy][osslconf]}

Единственное, что важно архитектурно: всё это относится к месту, где TLS терминируется. Если за вас терминирует CDN или балансировщик, гибридная группа нужна именно на этом участке, а конфигурация вашего origin — отдельный вопрос, как и канал между ними, то есть ровно тот внутренний отрезок, который забывают. Если вы терминируете в Kubernetes, это относится к шлюзу, и переход с ingress-nginx — естественный момент это сделать, раз вы всё равно переписываете эти объекты.^[rfc8446]

Инвентаризация, которую можно защитить на аудите

Всё сказанное выше — про отдельный хост. Аудиторы, да и вы сами через год, спросят про покрытие: не «починен ли этот эндпоинт», а «сколько их всего и какие не починены». Стройте список из источника истины, которому вы и так доверяете, а не из сканирования, чтобы отсутствие что-то значило:

#!/usr/bin/env bash
# pq-inventory.sh - a starting point, not a CBOM. One line per listener, with
# the negotiated group, so the output diffs cleanly between runs.
set -uo pipefail
printf '%-34s %-9s %-22s %s\n' HOST PORT GROUP NOTE

while IFS=: read -r host port; do
  out=$(openssl s_client -connect "$host:$port" -servername "$host" \
        -groups X25519MLKEM768:X25519 -tls1_3 </dev/null 2>/dev/null)
  grp=$(printf '%s' "$out" | sed -n 's/^Negotiated TLS1.3 group: //p')
  sig=$(printf '%s' "$out" | sed -n 's/^Peer signature type: //p')
  case "$grp" in
    *MLKEM*) note="pq-ok" ;;
    "")      note="no-tls1.3-or-unreachable" ;;
    *)       note="classical-only" ;;
  esac
  printf '%-34s %-9s %-22s %s (sig %s)\n' "$host" "$port" "${grp:--}" "$note" "${sig:--}"
done < endpoints.txt

# endpoints.txt is one host:port per line. Feed it from whatever you already
# trust as the source of truth - the load balancer config, Consul, the CMDB -
# rather than from a network scan, so that absence is meaningful.

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

1. Внешняя терминация TLS. Все публичные имена. Самый короткий список, самая высокая экспозиция, обычно чинится одним изменением на периметре.
2. SSH, везде. Сначала бастионы, потом всё, что доступно с них. Именно здесь всплывает длинный хвост из железок, сетевого оборудования и забытых виртуалок.
3. Внутренний TLS между сервисами. Service mesh, подключения к БД, брокеры сообщений. Список длиннее и труднее перечисляется, зато настройки самого меша могли уже решить задачу за вас.
4. VPN и site-to-site туннели. Долгоживущие, ценные и часто на вендорской прошивке со своим графиком обновлений. Начинайте разговор с поставщиком рано: это скорее закупочная проблема, чем техническая.
5. Всё встроенное. Устройства, агенты, принтеры, камеры, промышленные контроллеры. Задокументируйте, явно примите риск и поставьте дату у этого принятия.

Держите вывод пригодным для diff и перезапускайте по расписанию. Цифра, сдвинувшаяся не в ту сторону, — самый ранний сигнал, что пересобранный образ или откаченный пакет тихо отменил работу, и такой сбой гораздо чаще, чем неудачная миграция.

Подписи и сертификаты: почему стоит подождать

Теперь часть, где полезный совет — делать меньше. NIST стандартизировал в 2024 году две постквантовые схемы подписи, ML-DSA и SLH-DSA, обе реализованы в OpenSSL 3.5. Ключи можно сгенерировать уже сегодня. Класть их в цепочку сертификатов не стоит.^{[fips204][fips205][fips203]}

Причина ровно та, которую называет OpenSSH, объясняя приоритет согласования ключей: атаки «сохранить сейчас, подделать потом» не существует. Подпись должна быть неподделываемой только в момент проверки. Срочность по подписям связана не с защитой сегодняшнего трафика, а с тем, чтобы классические ключи подписи были выведены из эксплуатации до появления криптографически значимого квантового компьютера, — срок измеряется годами, а не перехваченными пакетами.^[pq]

Практические блокеры имеют форму экосистемы, и ни один из них не в вашей власти:

• Браузеры не доверяют ни одному постквантовому корню. Цепочка сертификатов стоит ровно столько, сколько корень, которому проверяющая сторона уже доверяет, а эти хранилища обновляются с многолетним шагом — и на то есть основания.
• Проблема размера реальна. Подписи и открытые ключи ML-DSA заметно больше, чем у ECDSA. В рукопожатии, несущем полную цепочку, это измеряется дополнительными round trip на каналах с потерями, а не абстрактными байтами.
• У OpenSSH есть лишь экспериментальная постквантовая схема подписи. Проект удалил экспериментальную поддержку XMSS в 10.1, а затем в 10.4 (июль 2026) добавил составную схему mldsa44-ed25519, объединяющую ML-DSA-44 и Ed25519. Она явно помечена как экспериментальная и не включена по умолчанию: её нужно самостоятельно добавить в HostKeyAlgorithms и PubkeyAcceptedAlgorithms, а ключи создать командой ssh-keygen -t mldsa44-ed25519. Знать об этом полезно; ставить под продуктивные ключи хоста — пока рано.^{[ssh104][mldsased][ssh101]}
• Согласиться должны все промежуточные звенья. В проверке сертификата участвуют ваш сервер, клиент, каждый инспектирующий middlebox и любой pinning, добавленный кем-то в 2019 году. Подписи отказывают «в закрытую» и сразу для всех.

Что же делать с подписями в 2026 году? Две вещи, обе дешёвые. Убрать алгоритмы, слабые уже по классическим причинам: DSA полностью исчез в OpenSSH 10.0, а подписи SHA-1 должны были уйти много лет назад. И сделать выпуск сертификатов автоматическим и короткоживущим, чтобы, когда постквантовые сертификаты станут выпускаемыми, замена была изменением конфигурации, а не проектом. Криптоагильность — не продукт, который покупают, а свойство уже уметь быстро ротировать, и хотеть его стоит по совершенно другим причинам. Здесь работает тот же инстинкт, что и за скучными архитектурами: экзотический вариант — не безопасный.^[ssh103]

Регуляторный календарь, изложенный точно

Сроки — то место, где технические статьи незаметно становятся неверными, поэтому вот аккуратная версия. NIST IR 8547, документ, на который все ссылаются ради тезиса «RSA устаревает в 2030-м», — это первоначальный публичный черновик, опубликованный в ноябре 2024 года. Период комментариев закрылся в январе 2025-го, полученные комментарии опубликованы. Он показывает ожидаемый подход NIST и является правильной основой для планирования, но цитировать его как окончательный обязывающий стандарт неточно — и кто-нибудь на вашем ревью это знает.^[ir8547]

Различие имеет практическое значение: черновик говорит, куда движется нижняя планка, и этого достаточно для планирования. Этого недостаточно, чтобы написать «требуется NIST» в проектном документе. Ссылайтесь на него как на черновик — и ваша программа переживёт первое серьёзное ревью.^[ir8547]

Европа идёт параллельным путём с другой механикой. Государства-члены приняли через Группу сотрудничества NIS согласованную дорожную карту внедрения: начать переход и запустить пилоты до конца 2026 года, завершить сценарии высокого риска и критическую инфраструктуру к 2030-му и закончить настолько полно, насколько практически возможно, к 2035-му. Это инструмент координации, а не регламент, но именно под него пишутся национальные дорожные карты — так что, если вы работаете в ЕС, это документ, который прочитал ваш отраслевой регулятор.^[euroadmap]

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

План на 90 дней

Если нужна вся картина на одной странице — вот она. Исходная посылка: согласование ключей — решённая задача, которую вы просто раскатываете, а всё остальное подготовка.

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

Пять ошибок, которых стоит избежать

Паттерны, регулярно всплывающие в реальных миграциях, примерно в порядке потерянного времени:

1. Аудит возможности вместо аудита согласования. «Наши серверы поддерживают ML-KEM» — не находка. Сервер может поддерживать его и при этом весь день завершать классические рукопожатия ради одного устаревшего клиента. Читайте согласованный алгоритм соединения, а не список поддерживаемых.
2. Удаление классических алгоритмов. Гибриды существуют именно для того, чтобы не приходилось выбирать. Постквантовая группа впереди, X25519 позади — защита без инцидента доступности.
3. Погоня за сертификатами. Время, потраченное в 2026 году на попытки развернуть сертификаты ML-DSA, — это время, не потраченное на обмен, который реально собирают. Автоматизируйте выпуск: именно эта работа окупится позже.
4. Остановка на периметре. Рукопожатие с CDN постквантовое, а канал до origin — нет. Это самый частый разрыв, потому что внешний тест проходит, а на внутреннем отрезке некому пожаловаться.
5. Отношение как к разовой задаче. Пересобранный базовый образ, зафиксированный пакет, откаченная конфигурация — и хост, соответствовавший требованиям в марте, в сентябре согласует классику. Повесьте обход на таймер и настройте оповещение на рост счётчика.

Коротко

Постквантовое согласование ключей — не проект будущего. Это значение по умолчанию, которое вы, скорее всего, уже унаследовали, и вся работа сводится к поиску соединений, мимо которых оно прошло. Обновитесь до OpenSSH 10.x и OpenSSL 3.5+, поставьте гибридную группу первой в обоих, обойдите парк и посмотрите, что согласуется на самом деле, и запишите исключения с датами. Для большинства команд это неделя работы, и она закрывает единственную атаку в этой области, которая идёт прямо сейчас.

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

Частые вопросы

Нужно ли что-то делать, если у меня уже OpenSSH 10?

Проверить — и, скорее всего, нет. По умолчанию используется mlkem768x25519-sha256, но базовый профиль харденинга, шаблон на основе CIS или модуль управления конфигурацией может содержать собственную строку KexAlgorithms, написанную до появления ML-KEM и молча его исключающую. Выполните ssh -v host exit 2>&1 | grep 'kex: algorithm' к реальному хосту и прочитайте согласованный результат. Для входящих сессий решает серверная сторона.

Сломает ли включение постквантового обмена старые клиенты?

Нет, если настроить его как предпочтение, а не как ограничение. И KexAlgorithms в SSH, и список групп в TLS — упорядоченные предпочтения: поставьте гибрид первым, оставьте curve25519-sha256 или X25519 позади, и современные узлы получат постквантовый обмен, а старые откатятся к классическому. Ломается всё тогда, когда классические записи удаляют полностью: для закрытого парка под полным контролем это защитимое решение, для чего-либо публичного — плохое.

Достаточно ли sntrup761x25519-sha512 или нужно переходить на ML-KEM?

Он действительно квантово-устойчив и уже сегодня останавливает атаку «собрать сейчас, расшифровать потом», а это и есть нужное свойство. Его слабость в стандартизации, а не в криптографии: NTRU Prime не был выбран NIST, поэтому он не удовлетворит режим соответствия, написанный вокруг FIPS 203, и долгосрочная поддержка реализаций менее определённа. Если вы на OpenSSH 9.0–9.8 и не можете обновиться в этом квартале, вы защищены. Переход на 9.9+ всё равно запланируйте.

Почему нельзя просто развернуть постквантовые сертификаты сейчас?

Потому что сертификат полезен только тогда, когда проверяющая сторона уже доверяет подписавшему его корню, а в хранилищах доверия браузеров нет ни одного постквантового корня. Сгенерировать ключи ML-DSA в OpenSSL 3.5 и поднять на них внутренний УЦ можно — для закрытой системы это разумный эксперимент. Но всё, к чему прикасается браузер, проверку цепочки не пройдёт. Это вопрос последовательности в экосистеме, а не конфигурации, и решается он годами.

Как проверить, что реально согласует мой TLS-эндпоинт?

openssl s_client -connect host:443 -servername host -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep 'Negotiated TLS1.3 group'. Для самого теста нужен клиент OpenSSL 3.5+: проверка более старым клиентом даёт ложноотрицательный результат, потому что ваш клиент никогда не предлагал эту группу. Всегда прогоняйте и контрольный тест с -groups X25519, чтобы убедиться, что вы усилили эндпоинт, а не сломали его.

Нужно ли беспокоиться об AES и SHA-256?

Нет. Алгоритм Гровера даёт квадратичное ускорение против симметричных примитивов, что фактически вдвое сокращает длину ключа: у AES-256 остаётся запас в 128 бит, SHA-256 остаётся достаточным. Вокруг AES-128 больше споров, но практической проблемой он не является. Алгоритмом Шора взламываются именно асимметричные схемы — RSA, ECDH, ECDSA, — и они и есть предмет этой статьи целиком.

А как быть с VPN, базами данных и очередями сообщений?

Правило то же, исполнение сложнее. В базовом протоколе WireGuard постквантового согласования ключей нет, и для гибридной схемы он опирается на механизм предварительно разделённого ключа. Поддержка IPsec целиком зависит от прошивки вашего вендора. TLS у баз данных и брокеров обычно следует собственному TLS-стеку рантайма, а не системному OpenSSL, поэтому проверяйте каждый по отдельности, а не считайте, что общесистемная настройка туда дошла. При этом такие каналы — самые ценные цели, потому что их полезная нагрузка и есть те самые долгоживущие конфиденциальные данные, ради которых ведётся сбор.

Это театр соответствия или реальная угроза?

Угроза реальна, но сдвинута во времени, и поэтому её легко оценить неверно в обе стороны. Никто не расшифровывает ваш трафик сегодня. Вопрос в том, останется ли перехваченный сегодня трафик чувствительным к середине 2030-х, и для медицинских карт, финансовых данных, юридических материалов, государственной переписки и долгоживущих учётных данных ответ очевидно утвердительный. Особенность именно этого риска в том, что смягчение почти ничего не стоит — обновление версии и одна строка конфигурации, — поэтому расчёт затрат и выгод не требует от вас верить в какую-либо конкретную дату.

Всё это предполагает, что базовая система стоит на месте, а она не стоит: в статье про обновление Ubuntu 24.04 до 26.04 на серверах разобрано обновление выпуска, которое меняет шесть таких умолчаний.

Источники

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

1. OpenSSH — Post-Quantum Cryptography (project page, FAQ and warning text)
2. OpenSSH 9.9 release notes (19 September 2024) — ML-KEM hybrid added; sntrup761x25519-sha512 gains its IANA name
3. OpenSSH 10.0 release notes (9 April 2025) — mlkem768x25519-sha256 becomes the default key agreement
4. OpenSSH 10.1 release notes (6 October 2025) — warning on non-post-quantum key agreement, WarnWeakCrypto
5. OpenSSH 8.5 release notes (3 March 2021) — sntrup761x25519-sha512@openssh.com replaces the older NTRU Prime hybrid, disabled by default
6. OpenSSH 10.3 release notes (2 April 2026)
7. OpenSSH 10.4 release notes (6 July 2026) — experimental mldsa44-ed25519 composite post-quantum signature scheme, not enabled by default
8. OpenSSH 10.5 release notes (11 August 2026) — current release at the time of writing
9. OpenSSH — full release notes index
10. ssh_config(5) — KexAlgorithms, WarnWeakCrypto, Match
11. sshd_config(5) — KexAlgorithms, HostKeyAlgorithms, Include
12. IETF draft-ietf-sshm-mlkem-hybrid-kex — hybrid ML-KEM key exchange for SSH
13. IETF draft-ietf-sshm-ntruprime-ssh — sntrup761x25519-sha512 for SSH (successor to the expired draft-josefsson document)
14. IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs — the composite signature scheme OpenSSH 10.4 implements
15. OpenSSL 3.5 series release notes — PQC support and hybrid groups preferred by default (3.5.0, 8 April 2025)
16. OpenSSL documentation — SSL_CTX_set1_groups_list(3), the TLS supported-groups list
17. OpenSSL documentation — SSL_CONF_cmd(3), the Groups command Apache passes through
18. nginx documentation — ssl_ecdh_curve in ngx_http_ssl_module
19. HAProxy configuration manual — ssl-default-bind-curves
20. IETF draft-ietf-tls-ecdhe-mlkem — hybrid ECDHE + ML-KEM groups for TLS 1.3
21. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
22. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
23. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
24. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
25. NIST IR 8547 (Initial Public Draft, 12 November 2024) — Transition to Post-Quantum Cryptography Standards
26. European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to PQC
27. Cloudflare — State of the post-quantum Internet in 2025
28. Cloudflare Radar — post-quantum encryption adoption (live figures)