SLH-DSA (Stateless Hash-based Digital Signature Algorithm) — стандарт постквантовой цифровой подписи на хеш-функциях, известный как SPHINCS+, утверждённый NIST как FIPS 205. В отличие от решёточных схем (см. ML-DSA), безопасность SLH-DSA опирается только на свойства криптографических хешей. Это делает её очень консервативным вариантом PQC, но с ценой в виде больших подписей (обычно 8–30 КБ).
*Где это полезно в Web3:* долговременные подписи и артефакты, где важна «надежность как у хеша»; резервные/гибридные подписи для протоколов, кошельков, архивных хранилищ.
См. также: ML-DSA, ML-KEM, Безопасность, BTQ Technologies.
Коротко о конструкции (без боли)
SLH-DSA (SPHINCS+) — это «пирамидка» из хеш-деревьев, которая позволяет без состояния (stateless) подписывать произвольное число сообщений:
- FORS — быстрый одноразовый подписчик фрагментов сообщения (Forest of Random Subsets).
- WOTS+ — одноразовые подписи на основе цепочек хешей (Winternitz One-Time Signature).
- Merkle/Hypertree — деревья для агрегирования одноразовых ключей и построения публичного ключа.
- Tweakable hash — «подстраиваемые» вызовы хеша для разделения доменов (разные роли, одинаковая примитивная функция).
Все операции — это хеширование и конкатенации; никакой «тяжёлой» математики. Отсюда — высокая криптографическая надёжность при корректной хеш-функции и параметрах.
Параметры и размеры
Набор параметров задаёт целевую стойкость (уровни NIST) и влияет на размеры/скорости. Практические ориентиры:
| Профиль (семейства) | Уровень стойкости | Подпись | Публичный ключ | Секретный ключ | Где применять |
|---|---|---|---|---|---|
| SLH-DSA-S (SHAKE-256, «малые») | Level 1–5 | ~8–17 КБ | 16–48 Б | 32–64 Б | Баланс размера/скорости; клиентские устройства |
| SLH-DSA-SHA2 (SHA2-256/512) | Level 1–5 | ~8–30 КБ | 16–48 Б | 32–64 Б | Консервативные среды с SHA2 |
| SLH-DSA-Haraka | Level 1–5 | ~7–20 КБ | 16–48 Б | 32–64 Б | Аппаратные домены (AES-NI), специал. ускорения |
Примечания:
- Публичные/секретные ключи очень малы (десятки байт), но подпись крупная (килобайты).
- Точные размеры зависят от параметров: высоты гипердерева, Winternitz-параметра, числа поддеревьев и др.
- По производительности: генерация/верификация — умеренные; объём сети/стореджа — главный компромисс.
Как устроена подпись (интуитивно)
Идея: вместо «математической головоломки» мы многократно применяем хеш по согласованной схеме:
- Сообщение m → случайность R и хеш H = Hash(R || PK || m)
- FORS: H разбивается на индексы → подписываются одноразовыми ключами, даются аутентификационные пути по Merkle
- WOTS+: формируется одноразовая подпись «корня» нижнего дерева
- Hypertree: поднимаемся вверх, добавляя пути в вышестоящих деревьях
- Итоговая подпись = (R, блоки FORS, цепочки WOTS+, пути Merkle по уровням)
Верификация повторяет хеш-вычисления снизу вверх и сверяет верхушку гипердерева с публичным ключом.
*Stateless*: подписчик не хранит счётчик одноразовых ключей, а детерминированно «прыгает» по деревьям из сидов → меньше риск «повторной подписи» одним и тем же одноразовым ключом.
Плюсы и минусы SLH-DSA
Плюсы
- Надёжность «как у хеша» (модель безопасности близка к стойкости используемых хеш-функций).
- Отсутствие сложной алгебры, хорошие доказательства безопасности.
- Очень маленькие ключи (pk/sk), удобны для хранилищ/идентификаторов.
Минусы
- Крупная подпись (КБ), повышает стоимость передачи/хранения, комиссию в ончейн-сетях.
- Верификация может быть медленнее решёточных схем при той же платформе.
- Выбор параметров влияет на UX: Winternitz и высота деревьев → компромисс «размер ↔ скорость».
Где применить в блокчейн-инфраструктуре
- Резервные/гибридные подписи транзакций и артефактов. Параллельно с классикой или ML-DSA: хранить критичные подписи там, где важнее долговечность, чем размер.
- Архивные/юридические доказательства. Подписание долгоживущих журналов, чекпойнтов, корней состояния. Большая подпись не критична, а «консервативная» стойкость — плюс.
- Аппаратные домены. Где есть ускорения AES/битовых примитивов (варианты с Haraka) и дорогой сетевой трафик не лимитирует.
- Оффчейн-подписи оракулов/мостов. Как дополнительный слой безопасности (вместе с ML-DSA) для долговременных корневых ключей.
Сравнение с альтернативами PQC
| Алгоритм | Класс | Подпись | Публичный ключ | Скорость | Профиль применения |
|---|---|---|---|---|---|
| SLH-DSA (SPHINCS+) | Хеш-базовый | 8–30 КБ | 16–48 Б | Средняя | Долговечные подписи, консервативная криптография |
| ML-DSA (Dilithium) | Решётки | 2.4–4.6 КБ | 1.3–2.6 КБ | Высокая | Массовые кошельки/валидаторы, хороший баланс |
| ECDSA/EdDSA | Эллипт. кривые | 64–96 Б | 32–64 Б | Очень высокая | Сегодняшний стандарт, но уязвим к Шору |
Вывод: SLH-DSA — отличный «якорь надёжности», но не оптимален для высокочастотных ончейн-подписей из-за размера.
Интеграция и UX
Гибридные подписи
- Совмещайте классику + SLH-DSA или ML-DSA + SLH-DSA для критичных операций:
tx содержит две подписи и правила приёма (на переходный период нужны обе).
- Для долговременных записей можно хранить только SLH-DSA как архивный слой.
Форматы
- Версионируйте algo=SLH-DSA в адресах/метаданных.
- В EVM-подобных сетях заранее оцените газ/комиссии: подпись КБ порядка → дороже calldata.
Производительность
- Профилируйте выбор семейства (SHAKE/SHA2/Haraka) под целевую платформу (CPU/ARM/HW).
- Используйте батч-верификацию и «плоские» пути Merkle, где совместимо.
Риски и лучшие практики
- Правильные параметры. Не снижайте уровни безопасности ниже рекомендованных; следите за Winternitz/высотой деревьев.
- Крипто-агильность. Заложите переключение семейства хеша без миграции бизнес-логики.
- Реализация. Константное время, защита от утечек, аккуратные проверки длин/индексов.
- Размеры. Планируйте хранилище/полосу: КБ-подписи в журналах и ончейн — это «логистический» фактор.
- Гибрид. Для пользовательских транзакций чаще практичнее ML-DSA; SLH-DSA — как «второй пояс» надёжности.
Мини-формулы и ориентиры
Оценка накладных по размеру (упрощённо):
Где вклад каждого уровня зависит от высоты деревьев, Winternitz-параметра и глубины гипердерева.
Выбор семейства:
Если важна скорость и умеренный размер → ML-DSA
Если важна «надёжность как у хеша» и малы pk/sk → SLH-DSA
Часто → гибрид ML-DSA + SLH-DSA для критичных артефактов
FAQ
SLH-DSA — это и есть SPHINCS+? Да. SLH-DSA — стандартизованное имя SPHINCS+ в FIPS 205.
Почему подписи такие большие? Это цена за хеш-безопасность и stateless-дизайн: вместо компактной алгебры — множество хеш-путей и одноразовых подпись-блоков.
Можно ли использовать SLH-DSA для всех транзакций в блокчейне? Технически да, но экономически часто невыгодно. Рассмотрите ML-DSA для массовых подписей и SLH-DSA для долгоживущих данных/бэкапов.
Как выбрать параметры? Ориентируйтесь на целевой уровень NIST (например, Level 3/5) и профиль платформы (SHAKE/SHA2/Haraka). Не занижайте глубины деревьев без анализа.
Нужен ли KEM вместе с SLH-DSA? Подпись даёт аутентичность. Для конфиденциальности каналов используйте ML-KEM (Kyber) или гибрид ECDH+ML-KEM.
Чек-лист интегратора
- Добавьте algo=SLH-DSA и гибриды в форматах подписей/адресов.
- Спроектируйте двойную подпись (ML-DSA + SLH-DSA) для критичных артефактов/чекпойнтов.
- Замерьте газ/комиссии и хранение: КБ-подписи → другая экономика.
- Выберите семейство (SHAKE/SHA2/Haraka) под целевую платформу; профилируйте верификацию.
- Проведите аудит реализации (константное время, границы массивов, RNG).
- Документируйте миграцию и правила приёма «двойных» подписей на переходный период.
См. также
FAQ
SLH-DSA — это и есть SPHINCS+? Да. SLH-DSA — стандартизованное имя SPHINCS+ в FIPS 205.
Почему подписи такие большие? Это цена за хеш-безопасность и stateless-дизайн: вместо компактной алгебры — множество хеш-путей и одноразовых подпись-блоков.
Можно ли использовать SLH-DSA для всех транзакций в блокчейне? Технически да, но экономически часто невыгодно. Рассмотрите ML-DSA для массовых подписей и SLH-DSA для долгоживущих данных/бэкапов.
Как выбрать параметры? Ориентируйтесь на целевой уровень NIST (например, Level 3/5) и профиль платформы (SHAKE/SHA2/Haraka). Не занижайте глубины деревьев без анализа.
Нужен ли KEM вместе с SLH-DSA? Подпись даёт аутентичность. Для конфиденциальности каналов используйте ML-KEM (Kyber) или гибрид ECDH+ML-KEM.
Чек-лист интегратора
- Добавьте algo=SLH-DSA и гибриды в форматах подписей/адресов.
- Спроектируйте двойную подпись (ML-DSA + SLH-DSA) для критичных артефактов/чекпойнтов.
- Замерьте газ/комиссии и хранение: КБ-подписи → другая экономика.
- Выберите семейство (SHAKE/SHA2/Haraka) под целевую платформу; профилируйте верификацию.
- Проведите аудит реализации (константное время, границы массивов, RNG).
- Документируйте миграцию и правила приёма «двойных» подписей на переходный период.