ML-DSA или ECDSA: переход подписей на постквантовые схемы

Выбор между ML-DSA и ECDSA — это та половина перехода на постквантовую криптографию, которая касается подписей. ECDSA на кривой P-256 даёт подписи длиной 64 байта и используется повсюду, но его взламывает алгоритм Шора. ML-DSA (FIPS 204, август 2024 года) устойчива к известным квантовым атакам и работает быстро, но её ключи и подписи занимают килобайты. В отличие от обмена ключами, где гибридный ML-KEM в браузерах уже включён по умолчанию, переход подписей в основном ещё впереди.

Коротко о главном

Скорость измерялась с помощью openssl speed на одном ядре Apple M4 Max. ML-DSA в OpenSSL написана на переносимом C; оптимизированные реализации подписывают в несколько раз быстрее.

Зачем нужна замена

ECDSA опирается на задачу дискретного логарифмирования на эллиптической кривой, которую алгоритм Шора эффективно решает на большом отказоустойчивом квантовом компьютере. Такой машины пока нет, а оценки того, когда она может появиться, сильно расходятся. Но у подписей есть свойство, которое определяет срочность перехода: если подпись подделают позже, это не отменит уже состоявшуюся аутентификацию. TLS-рукопожатие, аутентифицированное с помощью ECDSA в 2026 году, нельзя атаковать задним числом, как записанный обмен ключами. Заняться заранее нужно всем, чьи подписи должны оставаться надёжными много лет: ключами корневых и промежуточных CA, прошивками и цепочками загрузки, корневыми сертификатами для подписи кода, юридическими документами и долгосрочными архивами.

ML-DSA — подпись на основе решёток (происходит от CRYSTALS-Dilithium), стойкость которой опирается на задачи Module-LWE и Module-SIS; квантовых ускорений атак на неё, кроме универсальных, не известно. NIST IR 8547 (первый публичный проект) предлагает запретить ECDSA, EdDSA и RSA после 2035 года, а CNSA 2.0 от NSA требует ML-DSA-87 для систем национальной безопасности, причём первыми на неё переходят подписи программного обеспечения и прошивок.

Проблема размера

Миграцию затрудняет именно размер. Сервер TLS аутентифицируется цепочкой сертификатов и подписью в рукопожатии; с ECDSA ключи конечного и промежуточного сертификатов, их подписи, две встроенные метки SCT и подпись CertificateVerify в сумме занимают несколько сотен байт. С ML-DSA-44 те же элементы занимают около 14,7 КБ (два открытых ключа по 1 312 байт и пять подписей по 2 420 байт: две на сертификатах, две в SCT и подпись CertificateVerify), а с ML-DSA-65 — ещё больше. Из-за этого первая порция данных сервера (first flight) выходит за пределы начального окна перегрузки TCP, что добавляет лишние циклы обмена (round trips), и упирается в ограничения QUIC на усиление трафика.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

Решение для веб-PKI ещё только разрабатывается. В феврале 2026 года Chrome объявил, что собирается опираться на сертификаты на основе деревьев Меркла (Merkle Tree Certificates, Internet-Draft рабочей группы PLANTS в IETF), которые заменяют большинство подписей отдельных сертификатов короткими доказательствами включения, и что не планирует добавлять постквантовые сертификаты X.509 в своё нынешнее хранилище корневых сертификатов. CA/Browser Forum пока не одобрил ML-DSA для публично доверенных сертификатов TLS. Частные PKI уже могут выпускать сертификаты ML-DSA по RFC 9881, а OpenSSL 3.5 и новее, Bouncy Castle и другие библиотеки их поддерживают.

Гибридные и составные варианты

На переходный период многим системам нужны подписи, которые проходят проверку и у старых, и у новых клиентов или остаются стойкими, даже если один из алгоритмов будет взломан:

• Составные подписи (draft-ietf-lamps-pq-composite-sigs, пока Internet-Draft) задают единые идентификаторы алгоритмов, например ML-DSA-65 вместе с ECDSA P-256, и подпись такого алгоритма верна, только если обе её части проходят проверку. RFC 9980 для OpenPGP использует тот же подход с ML-DSA-65+Ed25519, а в OpenSSH 10.4 появился экспериментальный тип ключа ML-DSA-44+Ed25519.
• Двойные подписи — это две независимые подписи на одних и тех же данных (CMS допускает несколько структур SignerInfo, некоторые форматы документов разрешают несколько полей подписи), и каждая проверяющая сторона проверяет ту, которую понимает.
• Параллельные PKI выпускают и классические, и постквантовые сертификаты, а выбор оставляют клиентам: согласование в TLS уже поддерживает такую модель через signature_algorithms.

Что когда выбирать

• Публичные серверные сертификаты TLS, ключи доступа, OIDC и публичные JWT: сегодня ECDSA (или Ed25519); чтобы не пропустить переход, следите за работой браузеров и IETF.
• Частная PKI для долгоживущих сервисов и устройств: ML-DSA-65 или составная подпись ML-DSA и ECDSA, если есть проверяющие стороны обоих типов.
• Прошивки и безопасная загрузка: ML-DSA-87 или схемы на основе хеш-функций LMS, XMSS либо SLH-DSA, в зависимости от того, нужно ли вам соответствие CNSA 2.0.
• Подпись кода и пакетов: добавляйте ML-DSA к существующим подписям по мере того, как её начинают поддерживать экосистемы (Sigstore, поставщики ОС).
• Блокчейны: выбирать здесь не вам; для нескольких сетей есть предложения о постквантовых подписях, но ни одно из них не внедрено широко ни в Bitcoin, ни в Ethereum.
• Короткоживущие токены и сессии: ECDSA подходит, пока проверяющие стороны не перейдут на новые алгоритмы, ведь подделка опасна только сейчас, пока токены и сессии действуют.

Заметки о миграции

1. Проведите инвентаризацию всех ключей подписи и проверяющих сторон (поможет криптографический перечень компонентов, cryptographic bill of materials): запишите сроки жизни ключей и то, кто проверяет подписи.
2. Откажитесь от предположений о размере: столбцы баз данных, ограничения на размер HTTP-заголовков (подпись ML-DSA-65 в base64 занимает около 4,4 КБ), память смарт-карт, QR-коды и DNS-записи.
3. Сделайте алгоритмы согласуемыми: идентификаторы алгоритмов в форматах, списки разрешённых алгоритмов у проверяющих сторон и идентификаторы ключей, чтобы новые ключи можно было вводить рядом со старыми.
4. Начните с долгоживущих корневых сертификатов: уже сейчас создайте для частных PKI корневые и промежуточные CA на ML-DSA или на составных алгоритмах, потому что распространение корневых сертификатов занимает годы.
5. Измерьте производительность в реальных сценариях: задержку рукопожатия с более крупными цепочками, скорость подписания (в переносимом коде на порядок ниже, чем у ECDSA), проверку на устройствах с ограниченными ресурсами.
6. Следите за статусом FIPS и политик: FIPS 204 — окончательный стандарт, NIST IR 8547 пока остаётся проектом, составные подписи тоже пока описаны только в проектах, а правила WebPKI ещё не изменились.

Источники

• FIPS 204, стандарт цифровой подписи на основе модульных решёток
• FIPS 186-5, стандарт цифровой подписи
• RFC 9881, ML-DSA в X.509
• NIST IR 8547, первый публичный проект
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Программы корневых сертификатов Chrome, в том числе программа для квантово-устойчивых сертификатов
• NSA: вопросы и ответы о CNSA 2.0