Постквантовая криптография: лучшие алгоритмы для защиты блокчейна

Для сети это означает риск подделки транзакций и потери средств с адресов, чьи открытые ключи доступны.

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

Где у классической криптографии уязвимость

ECDSA и Ed25519 опираются на задачи из теории эллиптических кривых; RSA — на сложность факторизации больших чисел. На классических компьютерах эти задачи считаются вычислительно трудными при корректных параметрах и реализации. Алгоритм Шора подрывает это предположение для достаточно мощного квантового компьютера: он позволяет получить закрытый ключ из открытого.

В блокчейне публичность данных усиливает проблему. Транзакции и связанные с ними подписи сохраняются в реестре, а открытые ключи могут становиться видимыми в ходе использования адреса. Если атакующий получает возможность вывести ключ из такого публичного материала, он сможет подписывать новые транзакции от имени владельца. Конкретная уязвимость зависит от схемы адресации и того, какие данные уже раскрыты, но фундаментальный риск для классических схем один и тот же.

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

Квантовая угроза для блокчейна начинается не с даты появления компьютера. Она начинается с архитектуры, в которой формат подписи нельзя заменить без координированного обновления сети.

Отдельно стоит различать шифрование и цифровую подпись. В утверждённых NIST стандартах FIPS 203 описывает ML-KEM, механизм инкапсуляции ключа на основе CRYSTALS-Kyber. Это не алгоритм подписи транзакций. Для подписей в блокчейне важнее ML-DSA, SLH-DSA и, после финализации соответствующего стандарта, FN-DSA. Смешивать эти назначения — базовая ошибка при проектировании миграции.

Что стандартизировал NIST

13 августа 2024 года NIST опубликовал три финализированных стандарта постквантовой криптографии:

Для блокчейн-подписей центральный выбор среди уже финализированных стандартов — ML-DSA или SLH-DSA. Falcon интересен как схема с компактной подписью, но его стандартизацию и статус реализации необходимо оценивать отдельно: в представленных данных FIPS 206 указан как разрабатываемый стандарт. Нельзя обращаться с ним как с уже завершённым эквивалентом FIPS 204 и 205.

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

Для оценки миграции полезно сначала разделить функции:

• ML-KEM применим там, где протоколу нужно согласовать или инкапсулировать ключ. Сам по себе он не заменяет ECDSA при авторизации транзакций.
• ML-DSA предназначен для цифровых подписей и даёт стандартизированный решёточный вариант с балансом производительности и параметров.
• SLH-DSA предлагает альтернативное основание безопасности, не связанное с решётками, за счёт хеш-функций.
• FN-DSA интересен размером подписи, но инженерная сложность реализации выше, а статус стандартизации требует отдельной проверки.

ML-DSA и Falcon: решёточные подписи с разным профилем риска

ML-DSA, основанный на CRYSTALS-Dilithium, использует задачи на решётках, в частности Module-LWE. NIST выбрал его как основной стандарт подписей благодаря производительности и балансу характеристик. Для блокчейн-инженера это практичный кандидат на базовую миграцию: стандарт финализирован, назначение соответствует транзакционным подписям, а схема не требует опираться на одну лишь хеш-криптографию.

Однако «основной стандарт» не означает «бесплатная замена». Постквантовые ключи и подписи крупнее классических ECDSA и Ed25519. В блокчейне каждый дополнительный байт проходит через несколько уровней: сериализацию транзакции, мемпул, распространение по сети, проверку подписи и хранение в блоке. Если блок ограничен по размеру или пропускной способности, увеличение подписи меняет экономику протокола и его фактическую производительность.

Falcon использует NTRU-решётки и выделяется меньшим размером подписи среди рассматриваемых решёточных алгоритмов. Это ценно для сетей, где пропускная способность и объём блоков являются узким местом. Но компактность оплачивается сложностью реализации. В алгоритме есть операции с плавающей запятой и гауссов семплер; значит, возрастает поверхность для ошибок в численной обработке, переносимости между платформами и побочных каналах.

Для блокчейна недостаточно показать, что подпись корректно проверяется на одной машине. Валидация должна давать согласованный результат на узлах с разными архитектурами и компиляторами. Любая неоднозначность в вычислениях может превратиться в проблему консенсуса или в уязвимость реализации. Поэтому преимущество Falcon по размеру имеет смысл считать вместе с затратами на аудит, тестирование и поддержку реализаций.

Конкретное решение зависит от профиля сети. Если приоритетом является опора на финализированный стандарт для подписей, ML-DSA выглядит прямолинейнее. Если лимит данных в блоке критичен, Falcon заслуживает бенчмарка, но экономия байтов не отменяет требований к аудиту и совместимости.

SPHINCS+ как независимая хеш-ориентированная альтернатива

SPHINCS+, стандартизированный как SLH-DSA в FIPS 205, строится на хеш-функциях, а не на решётках. Это важно для диверсификации криптографических предположений. Если проект не хочет держать безопасность всей миграции на одном семействе математических задач, хеш-ориентированная схема добавляет альтернативный профиль защиты.

Цена такой независимости — производительность и объём. По приведённым данным, SPHINCS+ работает медленнее Dilithium и генерирует значительно более крупные подписи. Для блокчейна это затрагивает сразу два ресурса: пропускную способность и вычислительные затраты при проверке транзакций. В системе с большим числом подписей на блок такое решение может оказаться тяжёлым даже при приемлемой безопасности на уровне алгоритма.

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

Сравнение трёх схем для транзакционных подписей выглядит так:

У таблицы есть важное ограничение: она не заменяет бенчмарк конкретной реализации. Результат зависит от параметров алгоритма, платформы валидатора, способа сериализации, размера блока и того, как протокол тарифицирует вычисления. Сравнение названий без одинакового тестового стенда даёт мало полезной информации.

Как оценивать переход в блокчейне

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

При проектировании перехода имеет смысл проверить несколько уровней:

1. Формат транзакции. Новая подпись может заметно увеличить полезную нагрузку. Нужно оценить, как это влияет на размер блока, комиссионную модель и число транзакций, которые помещаются в блок.

2. Верификация на валидаторах. Бенчмарк должен измерять проверку подписей под нагрузкой, а не только скорость одной операции на изолированной машине. Для консенсусной сети важен худший реалистичный сценарий.

3. Сетевое распространение. Большие транзакции требуют больше трафика при передаче и могут менять поведение мемпула. Это особенно существенно для узлов с ограниченными ресурсами.

4. Совместимость клиентов. Разные реализации протокола должны одинаково кодировать и проверять подписи. Расхождение между клиентами — потенциальная консенсусная уязвимость.

5. Миграция ключей. Нужно описать, как пользователь переводит средства с классического адреса на постквантовый и какие гарантии действуют для адресов, чьи открытые ключи уже раскрыты.

6. Срок поддержки старых схем. Переходный период упрощает совместимость, но увеличивает поверхность атаки и усложняет правила валидации. Его границы должны быть частью протокольной спецификации.

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

Для Falcon отдельно нужен аудит численной части и анализ побочных каналов. Для ML-DSA — проверка выбранной реализации, корректности параметров и устойчивости к ошибкам интеграции. Для SLH-DSA — оценка того, выдержит ли сеть объём подписей и проверок при заданных лимитах. Стандарт снижает неопределённость в алгоритме, но не исправляет плохой код и не снимает ограничения архитектуры.

В блокчейне размер подписи превращается в сетевой расход, а скорость проверки — в часть пропускной способности. Это параметры протокола, не мелочи библиотеки.

Вердикт: какой алгоритм выбирать

Для базового перехода на постквантовые подписи наиболее обоснованный кандидат из финализированных стандартов — ML-DSA, то есть CRYSTALS-Dilithium по FIPS 204. У него подходящее назначение, решёточное основание и статус основного стандарта NIST для подписей. Это не делает его автоматически лучшим для каждой сети, но даёт наиболее ясную исходную точку для проектирования и испытаний.

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

SLH-DSA полезен как хеш-ориентированная альтернатива с другим основанием безопасности. Его крупные подписи и более медленная работа делают его тяжёлым выбором для массовых транзакций, если сеть не может обосновать этот оверхед конкретной моделью угроз.

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