ML-DSA (Module Lattice–based Digital Signature Algorithm) — стандарт постквантовой цифровой подписи на модульных решётках (семейство Dilithium), принятый в NIST как FIPS 204. Он призван заменить/дополнить классические ECDSA/EdDSA, устойчивые к «обычным» атакам, но уязвимые к квантовым (алгоритм Шора). ML-DSA вместе с ML-KEM (FIPS 203, Kyber) и SLH-DSA (FIPS 205, SPHINCS+) образует «ядро» стандартизованной PQC (post-quantum cryptography).
*Для чего в Web3:* защита кошельков, протоколов, RPC и корпоративных систем на горизонте «квантовых рисков». В блокчейн-мире ожидается гибридный период: параллельное применение классики и PQC.
См. также: Безопасность в крипте, Bitcoin, Ethereum, BTQ Technologies.
Коротко о математике (без боли)
- Основание безопасности: задачи module-LWE/LWR над кольцом полиномов \( R_q = \mathbb{Z}_q[x]/(x^{256}+1) \) с простым модулем \( q = 8380417 \).
- Идея подписи: коммитмент → хэш-вызов (Fiat–Shamir) → ответ с rejection-sampling, чтобы выходы выглядели «правдоподобно случайными».
- Хэш-функции: SHAKE-128/256 (XOF) — и для расширения сидов, и для вычисления челленджа.
- Детерминизм с солью: подпись может быть детерминированной (из ключа и сообщения) с опциональной «солёной» рандомизацией для защиты от сайд-чейнов.
Вам не нужно понимать решётки, чтобы пользоваться ML-DSA. Важно знать: большие ключи/подписи, быстрые операции, и никаких зависимостей от эллиптических кривых.
Параметры и размеры (что попадёт в ваш протокол)
| Профиль (FIPS 204) | Категория стойкости (NIST) | Публичный ключ | Секретный ключ | Подпись | Типичные применения |
|---|---|---|---|---|---|
| ML-DSA-44 (≈ Dilithium-2) | Level 2 | ~1.3 KB | ~2.5 KB | ~2.4 KB | Пользовательские устройства, кошельки |
| ML-DSA-65 (≈ Dilithium-3) | Level 3 | ~1.95 KB | ~4.0 KB | ~3.3 KB | Биржи, валидаторы, корпоративные сервисы |
| ML-DSA-87 (≈ Dilithium-5) | Level 5 | ~2.6 KB | ~4.9 KB | ~4.6 KB | Критичные контуры, долговременные ключи |
Примечания:
- Точные байтовые размеры зависят от реализации/энкодинга, но порядок величин — такой.
- В 40–70 раз больше, чем у ECDSA-secp256k1 по подписи (но при этом — высокая скорость на CPU).
- Публичные ключи кодируются компактно; верификация часто быстрее, чем у «тяжёлых» альтернатив (например, у чисто хешевых SQISign/SLH-DSA — другая картина по размерам/скоростям).
Производительность: где «узкие места»
- Клиентские устройства. ML-DSA работает быстро на обычных CPU/ARM: тысячи подписей/сек на десктопе, сотни — на смартфонах.
- Серверы/валидаторы. Верификация масштабируется; батчи дают хорошие TPS. Для экстремальных нагрузок пригодятся аппаратные оптимизации (PIM/инструкции) и SIMD.
- Сеть/сторедж. Главный «ценник» — размер подписи в транзакциях/блоках и в state. В UX это значит: чуть больше газа/комиссий и времён передачи.
Как это работает (жизненный цикл ключей и подписи)
Генерация ключей (KeyGen)
Вход: seed
Расширить seed через SHAKE → матрица A и секретные векторы s1, s2.
Вычислить t = A·s1 + s2 (в кольце R_q), разложить на (t1, t0).
Публичный ключ: pk = (ρ, t1); секретный: sk = (ρ, K, tr, s1, s2, t0).
Подпись (Sign)
Вход: sk, сообщение m
μ = H(tr | | m); создать случайный вектор y из XOF(sk, m).
w = A·y; c = H(μ | | w1).
z = y + c·s1; проверка границ и «rejection-sampling».
Подпись: (z, h, c) / / сжатые компоненты.
Проверка (Verify)
Вход: pk, m, (z, h, c)
Проверить «норму» z; восстановить w' из pk, z, c.
Сравнить c с H(μ | | w'1). Совпало → валидно.
На практике всё прячется в библиотеку; контракты видят только байтовые строки.
Где ML-DSA в блокчейне/крипте
- Кошельки и подписи транзакций. Планы «гибридных» кошельков: ECDSA/EdDSA + ML-DSA. Это даёт обратную совместимость с существующей сетью и «страховку» на будущее.
- RPC/релеи/оракулы. Защита от «хранения-сейчас-взлома-потом» (harvest-now-decrypt-later): подписывать данные/каналы PQC-ключами уже сегодня. См. Оракул.
- Корпоративные кастоди/биржи. Внутренние подписи, чек-апрувы, архивные хранилища — перевод на PQC снижает риски ретро-взлома.
- Новые L1/L2. Проще, чем мигрировать старые сети: сразу выбрать ML-DSA или гибрид.
См. также: BTQ Technologies (PQC-SDK и демо), Безопасность.
Миграция: практическая стратегия для Web3-команд
1) Крипто-агильность в коде
- Абстрагируйте подпись: интерфейс sign/verify с указанием алгоритма/версии.
- Версионируйте адрес/публичный ключ (bech32/CBOR/SSZ с полем algo).
2) Гибридные подписи
- Транзакция несёт две подписи (классика + ML-DSA) или агрегированную структуру.
- Правило приёма: сеть/узлы принимают, если обе (или одна, согласно фазе миграции) валидны.
3) Форматы и газ
- Для EVM: прятать большие подписи в calldata/логах дороже; нужен EIP-дизайн/прекомпилы.
- Для UTXO: новые witness-типы/OP-коды и полис размера блока.
4) Управление ключами
- Большие ключи/подписи → HSM/TEE с поддержкой XOF/SHAKE и «широких» ключей.
- Ротация и отзыв: планы «переиздания» адресов, метаданные совместимости.
5) Производительность
- Бенчмарки на целевом железе; оценка TPS и latency.
- Если узко — применить аппаратные ускорители (см. PIM/QCIM в BTQ).
6) UX и риск
- Пользователю — простой «переключатель» алгоритма и понятные предупреждения.
- Документация: «почему подписи стали больше», «зачем это всё».
Сравнение с альтернативами PQC
| Алгоритм | Класс | Подпись (байт) | pk (байт) | Скорость | Плюсы | Минусы |
|---|---|---|---|---|---|---|
| ML-DSA (Dilithium) | Решётки | ~2.4–4.6K | ~1.3–2.6K | Высокая | Баланс размера/скорости, простая проверка | Подпись крупнее ECDSA |
| SLH-DSA (SPHINCS+) | Хеш-подписи | ~8–30K | ~16–32 | Безопасность на хешах, без матем. допущений | Очень большие подписи | |
| (Классика) ECDSA/EdDSA | Эллипт. кривые | 64–96 | 32–64 | Отличная | Компактно, дешево | Уязвимо к квантовым атакам |
*Практика*: в гибриде ML-DSA + ECDSA получаем компактность и PQC-страховку.
Риски и лучшие практики
- Сайд-чейны/время выполнения. Реализация обязана быть константного времени; избегайте ветвлений по секретным данным.
- Fault-injection. Защита от «глитчей», проверки длин/границ массивов, отказ при несоответствии.
- Случайность. При детерминированной подписи используйте добавочную соль (rand), чтобы усложнить утечки побочных каналов.
- Хранение ключей. Большие ключи = новые требования к бэкапам; зашифрованные контейнеры, разделение на шёрами (Shamir).
- Политики жизни ключей. Меньше «мульти-сроков» и длительных reuse; ротация по расписанию.
- Совместимость. Ясная политика: где нужна двойная подпись, где достаточно одной; версия протокола в сообщении.
Мини-FAQ
ML-DSA — это «тот самый» Dilithium? Да. ML-DSA — стандартизованная форма семейства Dilithium с конкретными профилями и форматами.
Почему подпись такая большая? Так устроены решёточные схемы. Компенсируется скоростью и безопасностью против квантовых атак. На практике используют компромиссы формата/газа и гибрид.
Это готово для мейннета биткоина/эфира? Пока в виде исследований/экспериментов и дорожных карт. Нужны протокольные изменения (форматы транзакций/прекомпилы) и широкая поддержка клиентов.
Что выбрать: ML-DSA-44/65/87? Для кошельков/массовых клиентов — 44; для бирж/валидаторов — 65; для долгоживущих ключей/архивов — 87.
Чек-лист интегратора
- Введите algo=ML-DSA в ваших интерфейсах подписи; храните pk/sk в стандартизованных контейнерах.
- Добавьте гибридные подписи (классика + ML-DSA) в транзакции/сообщения.
- Протестируйте TPS/газ/латентность; при необходимости — аппаратное ускорение.
- Обновите HSM/TEE и процедуры бэкапа/ротации.
- Обозначьте миграционные фазы для пользователей и партнёров; логируйте версии ключей и алгоритмов.
- Проведите аудит реализации и тесты на сайд-чейны/ошибки памяти.