Алгоритмы шифрования данных: выбор для Web3-инфраструктуры

А приватность, достигнутая за счёт того, что интерфейс временно не показывает данные пользователю, не имеет отношения к криптографии.

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

Поэтому выбор алгоритма шифрования данных начинается не с вопроса, что быстрее — AES или ChaCha20. Сначала нужно определить, что именно защищается: транзакция, закрытый ключ, payload dapp, резервная копия, межсервисный канал или состояние, которое не должно попадать в публичный мемпул.

Подпись транзакции — не шифрование

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

В зависимости от экосистемы применяются разные схемы:

• ECDSA на secp256k1 — типичный выбор для Ethereum-подобных сетей и совместимых кошельков;
• Ed25519 — схема EdDSA с 32-байтными приватными и публичными ключами и 64-байтной подписью;
• sr25519 — схема Schnorrkel/Ristretto на базе Curve25519, используемая в экосистеме Polkadot;
• BLS12-381 — эллиптическая кривая, ориентированная на агрегацию подписей и работу с крупными наборами валидаторов.

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

Для приватности применяется другой слой. Данные шифруются симметричным ключом, а сам ключ может передаваться или храниться с использованием асимметричной криптографии. В более сложных системах добавляются zk-SNARKs, commitment-схемы, threshold cryptography и MPC. Но ни одна из этих технологий не превращает обычную ECDSA-подпись в механизм конфиденциальности.

Подпись отвечает на вопрос «кто это отправил и не изменилось ли сообщение». Шифрование отвечает на другой вопрос: «кто вообще имеет право увидеть содержимое».

Что происходит на уровне ключей

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

Типовая архитектура защищённого dapp выглядит так:

1. Клиент генерирует случайный симметричный ключ для объекта или сессии.

2. Данные шифруются через AEAD-режим — например, AES-256-GCM или ChaCha20-Poly1305.

3. Симметричный ключ защищается ключом получателя или передаётся через протокол установления общего секрета.

4. В ciphertext включаются nonce и дополнительные аутентифицированные данные.

5. Получатель проверяет тег аутентификации и только после этого расшифровывает payload.

Критическая деталь — AEAD одновременно обеспечивает конфиденциальность и контроль целостности. Простое шифрование без аутентификации оставляет систему уязвимой к модификации ciphertext. В контексте Web3 это означает возможность подменить параметры заявки, состояние ордера, данные разрешения или сообщение между сервисами без обнаружения на транспортном уровне.

BLS12-381: масштабируемость подписи, а не шифрование

BLS12-381 часто появляется в обсуждениях приватности и безопасности Web3, потому что кривая используется в инфраструктуре с большим количеством валидаторов и в системах доказательств. Но её назначение в данном контексте — цифровые подписи и операции над группами, а не симметричное шифрование данных.

Главное преимущество BLS — агрегация подписей. Тысячи индивидуальных подписей можно свернуть в одну агрегированную подпись и затем проверить одной операцией или существенно меньшим числом операций, чем при последовательной проверке каждого элемента. Это снижает объём данных, который нужно передавать и хранить в блоке.

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

Однако агрегация создаёт собственные требования к архитектуре:

• нужно корректно связывать подписи с сообщениями и контекстом домена;
• необходимо предотвращать rogue-key attacks;
• проверка агрегированной подписи не должна приниматься без валидации исходных публичных ключей;
• схема должна учитывать replay protection и разделение сетей, эпох и типов сообщений;
• компрометация процедуры генерации или проверки ключей может разрушить безопасность всей группы.

BLS12-381 не заменяет AES-256-GCM и не является альтернативой ChaCha20-Poly1305 для шифрования файлов или API-трафика. Это другой слой протокола. Смешение этих функций — не терминологическая мелочь, а архитектурная ошибка.

sr25519 и Ed25519: компактные подписи с разными профилями

Ed25519 использует 32-байтные ключи и 64-байтную подпись. Схема стандартизована в RFC 8032 и по конструкции устойчива к ряду timing side-channel атак. Это не означает автоматическую безопасность реализации: ошибки в генераторе случайности, хранении ключей, обработке ошибок и сериализации остаются отдельными векторами атаки.

sr25519 построена на Schnorrkel/Ristretto и применяется в Polkadot. Её архитектура рассчитана на Schnorr-подписи и работу с контекстом, где необходимы более гибкие схемы агрегирования и мультиподписи. Здесь также нельзя ограничиваться названием кривой. Реальный профиль безопасности определяется библиотекой, способом генерации nonce, форматом signed payload и тем, как протокол связывает подпись с chain ID, эпохой и типом операции.

При выборе схемы для dapp или блокчейн-сервиса нужно оценивать не только размер подписи:

• совместимость с аппаратными кошельками;
• наличие аудированных библиотек;
• корректность работы с deterministic nonce;
• поведение при восстановлении ключа;
• поддержку multisig и threshold-сценариев;
• стоимость верификации на целевой виртуальной машине;
• формат адресов и сериализации;
• устойчивость SDK к подмене домена подписи.

Последний пункт особенно неприятен в прикладных системах. Если пользователь подписывает сообщение, а клиент не отображает домен, chain ID, срок действия и назначение разрешения, криптографически корректная подпись всё равно может быть выдана на вредоносный payload. Криптография не исправляет плохой UX-дизайн, который скрывает семантику операции.

AES-256-GCM и ChaCha20-Poly1305: рабочий слой защиты данных

Для хранения и передачи данных в Web3-инфраструктуре обычно выбирают AEAD-алгоритмы. На практике главная конкуренция идёт между AES-256-GCM и ChaCha20-Poly1305. Оба дают конфиденциальность и аутентификацию, но предъявляют разные требования к железу и управлению nonce.

AES-256-GCM использует ключ длиной 256 бит и nonce размером 96 бит. При корректной реализации он обеспечивает 128-битную стойкость против алгоритма Гровера, то есть не следует считать AES-256 эквивалентом 256-битной постквантовой стойкости. Квантовая модель снижает эффективный запас для поиска ключа, но не делает AES-256 бесполезным.

AES-GCM особенно эффективен на современных процессорах с аппаратным ускорением AES-NI. Для серверной инфраструктуры, RPC-шлюзов, indexer-сервисов и высоконагруженных API это может дать существенный выигрыш по throughput и снизить нагрузку на CPU. Но бенчмарк нужно проводить на конкретной архитектуре. Результат на сервере x86 с AES-NI ничего не доказывает для мобильного устройства, ARM-платы или окружения, где аппаратное ускорение отключено.

ChaCha20-Poly1305 работает как потоковый шифр с полиномиальным механизмом аутентификации. Он хорошо показывает себя на устройствах без AES-NI и обычно проще масштабируется на программных реализациях. Это делает его практичным выбором для мобильных клиентов, edge-устройств и части embedded-сценариев.

Сводное сравнение выглядит так:

Выбор алгоритма шифрования данных нельзя делать по принципу «AES считается стандартом, значит он лучше». Стандартность — аргумент в пользу совместимости и зрелости экосистемы, но не замена измерениям. Если инфраструктура работает на процессорах без AES-NI, ChaCha20-Poly1305 может иметь более рациональный performance profile. Если сервис обрабатывает большие объёмы данных на CPU с аппаратным AES, AES-256-GCM часто будет предпочтительнее.

Nonce: маленькое поле с большим радиусом поражения

Nonce не обязан быть секретным. Но он должен быть уникальным в рамках конкретного ключа. Повторное использование nonce в AEAD-режиме может раскрыть отношения между plaintext и разрушить аутентификационную модель. Для AES-GCM это один из наиболее опасных классов ошибок интеграции.

Проблема особенно заметна в распределённых системах. Несколько воркеров шифруют данные параллельно. Часть запросов повторяется после таймаута. Состояние генератора случайных чисел восстанавливается из snapshot. Ключ переиспользуется между сервисами. В журнале или очереди повторно доставляется уже обработанное сообщение. Каждая из этих ситуаций может превратить управление nonce в скрытую уязвимость.

96-битный nonce AES-GCM — это не лицензия на небрежную генерацию. Проект должен определить:

• генерируется ли nonce случайно или счётчиком;
• кто отвечает за уникальность;
• сохраняется ли состояние счётчика при рестарте;
• может ли один ключ использоваться несколькими инстансами;
• как обрабатывается rollback snapshot;
• включается ли идентификатор ключа в дополнительные аутентифицированные данные;
• существуют ли лимиты на объём данных под одним ключом.

XChaCha20 расширяет nonce до 192 бит. Это существенно снижает риск коллизий при случайной генерации и делает алгоритм удобнее для распределённых систем, где трудно поддерживать единый глобальный счётчик. Но XChaCha20 не устраняет все ошибки. Если разработчики повторно используют ключи без контроля контекста, отключают проверку тега или неправильно сериализуют nonce, более длинное поле не спасёт протокол.

Практичный формат ciphertext должен явно хранить версию схемы, идентификатор ключа, nonce и зашифрованное содержимое. Метаданные могут быть открытыми, но должны входить в authenticated associated data, если их подмена меняет интерпретацию сообщения.

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

Длинный nonce снижает вероятность коллизии. Он не компенсирует отсутствие модели управления ключами.

Где находится приватность блокчейна

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

В Web3 применяются несколько подходов:

1. Шифрование off-chain payload. Сами данные хранятся вне блокчейна, а в реестр отправляется commitment, хэш или ссылка на объект. Такой вариант снижает нагрузку на сеть, но переносит доверие к системе хранения и управлению ключами.

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

3. Доказательства с нулевым разглашением. Участник доказывает соответствие условиям, не раскрывая исходные данные. Это требует circuit design, trusted setup либо transparent setup в зависимости от системы, а также контроля witness и схемы публичных входов.

4. Пороговое управление ключами. Секрет распределяется между несколькими участниками. Для восстановления требуется quorum. Это снижает риск компрометации одного узла, но усложняет recovery, ротацию и аудит.

5. Гибридная архитектура. Симметричный алгоритм защищает данные, а доступ к симметричному ключу контролируется асимметричной схемой, multisig или MPC.

На практике чаще всего ломается не сам алгоритм, а граница между слоями. Ключ AES хранится в том же bucket, что и ciphertext. Ключ расшифрования попадает в логи. Сервис принимает nonce от клиента без проверки. Смарт-контракт публикует commitment, но исходные данные остаются доступны через API. ZK-доказательство скрывает значение, однако раскрывает уникальный идентификатор, по которому его легко связать с другой активностью.

Если задача проекта — не криптографическое исследование, а защита пользовательских данных, полезнее сначала разобрать базовые практические советы по цифровой безопасности, а уже затем выбирать конкретный primitive для протокола. AES-256-GCM не исправит отсутствие ротации ключей и избыточные права сервисного аккаунта.

Аппаратная оптимизация и side-channel

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

AES-256-GCM выигрывает там, где доступны AES-NI или аналогичные аппаратные инструкции. Они ускоряют раунды AES и операции, необходимые для GCM. В высоконагруженных сервисах это уменьшает стоимость шифрования на запрос и снижает latency. Но при переносе кода на другую архитектуру профиль меняется.

ChaCha20-Poly1305 не требует специализированного криптографического блока и хорошо подходит для постоянного программного исполнения. Это упрощает переносимость и уменьшает зависимость от конкретного CPU. Впрочем, переносимость не означает отсутствие side-channel рисков. Реализация должна быть constant-time там, где это требуется, а обработка ошибок не должна раскрывать различия между неверным тегом, отсутствующим ключом и повреждённым форматом.

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

• незащищённую память процесса;
• swap и дампы;
• трассировку исключений;
• журналы с фрагментами секретных данных;
• предсказуемый генератор случайных чисел;
• аппаратные атаки на устройство;
• повторное использование nonce в схеме подписи;
• ошибочную очистку буферов.

Аппаратный кошелёк сокращает поверхность атаки, но не делает подпись безопасной автоматически. Если пользователь не видит полный payload, вредоносный dapp может использовать корректный механизм подписи для легитимного, но нежелательного разрешения. В EVM-экосистеме это часто касается permit-подписей, allowance и делегирования полномочий. Защита ключа и понимание подписываемого сообщения — разные задачи.

Что измерять в бенчмарке

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

• throughput для малых сообщений, характерных для API и транзакционных payload;
• throughput для крупных объектов и резервных копий;
• latency на одну операцию шифрования и расшифрования;
• потребление CPU на сервере и клиентском устройстве;
• стоимость генерации и хранения nonce;
• поведение при параллельной обработке;
• влияние ротации ключей;
• размер дополнительного overhead;
• поведение после рестарта и восстановления snapshot;
• корректность обработки повреждённого ciphertext.

Измерять нужно не только успешную расшифровку. Отдельный тест обязан проверять неверный тег, изменённые associated data, повтор nonce, неизвестную версию формата и отсутствующий ключ. Именно эти ветки чаще всего оказываются менее проработанными, чем happy path.

Для Web3-системы к этому добавляется стоимость в конкретной среде исполнения. Операция, дешёвая на уровне ноды, может стать дорогой внутри виртуальной машины смарт-контракта. А алгоритм, который невозможно эффективно реализовать on-chain, следует вынести off-chain и связать с состоянием через commitment или доказательство.

Постквантовый аспект: без рекламных сокращений

Постквантовая устойчивость требует разделять симметричные и асимметричные примитивы. Нельзя утверждать, что secp256k1, ECDSA, Ed25519 или BLS12-381 защищены от достаточно мощного квантового компьютера без использования гибридных постквантовых схем. Их безопасность основана на задачах, для которых известны квантовые атаки с принципиально иным профилем сложности.

Для AES-256 ситуация другая. Алгоритм Гровера теоретически уменьшает эффективную стойкость поиска ключа примерно до уровня 128 бит. Это не означает, что AES-256 уже устарел или требует немедленной замены. Но долгоживущие данные, которые должны оставаться конфиденциальными десятилетиями, следует проектировать с учётом миграции ключей и криптографической гибкости.

В инфраструктуре разумно разделять:

• ключи шифрования данных;
• ключи аутентификации сервисов;
• ключи подписи транзакций;
• ключи управления доступом;
• ключи, используемые в доказательствах и commitment-схемах.

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

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

Как выбирать алгоритмы для Web3-проекта

Практический выбор можно свести к архитектурному профилю.

Если требуется подписывать транзакции

Выбирается схема, совместимая с целевой сетью, кошельками и средой исполнения. Для Ethereum-подобной инфраструктуры это обычно secp256k1. Для экосистемы Polkadot — sr25519. Для систем с массовой агрегацией подписей — BLS12-381. Ed25519 подходит там, где он поддерживается протоколом и инфраструктурой ключей.

Здесь определяющими становятся формат payload, защита nonce подписи, domain separation, chain ID и аппаратная поддержка. Нельзя выбрать алгоритм только по длине ключа.

Если требуется шифровать данные API и хранилища

AES-256-GCM рационален на серверах с AES-NI. ChaCha20-Poly1305 — практичный вариант для устройств без аппаратного ускорения AES. XChaCha20-Poly1305 удобнее в распределённых системах, где нужна большая свобода при генерации nonce.

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

Если требуется скрывать факт соответствия условию

Рассматриваются zk-SNARKs или другие ZK-протоколы. Само шифрование здесь не решает задачу. Оно скрывает данные от неавторизованного читателя, но не позволяет третьей стороне проверить утверждение без доступа к plaintext.

Если требуется коллективное управление

Используются multisig, threshold signatures или MPC. BLS может снизить overhead в схемах агрегации, но не является универсальным решением для распределённого доступа. Нужно отдельно проектировать восстановление, отзыв участника и аудит quorum-логики.

Если данные должны пережить смену криптографических стандартов

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

Технический вердикт

У Web3 нет одного «лучшего» алгоритма шифрования данных. Есть набор примитивов с разными границами применимости.

• secp256k1, Ed25519, sr25519 и BLS12-381 решают задачи подписи, идентификации и агрегации.
• AES-256-GCM подходит для серверов с аппаратным AES-ускорением и требует строгого контроля nonce.
• ChaCha20-Poly1305 сохраняет предсказуемую производительность без AES-NI.
• XChaCha20-Poly1305 снижает риск коллизий nonce в распределённых системах за счёт 192-битного nonce.
• zk-SNARKs нужны для доказательства утверждений без раскрытия исходных данных, а не для замены обычного AEAD.
• Мультиподпись, threshold cryptography и MPC закрывают проблему распределённого управления ключами, но добавляют сложность recovery и аудита.

Основная уязвимость обычно находится не в математике примитива. Она появляется в протоколе генерации nonce, жизненном цикле ключей, сериализации payload, обработке ошибок или связке между on-chain и off-chain компонентами.

Если анализ исходного кода показывает самодельный формат ciphertext, общий ключ для нескольких сервисов, отсутствие domain separation и неописанную стратегию ротации, обсуждение разницы между AES и ChaCha20 преждевременно. Сначала исправляется архитектура. Затем выполняется бенчмарк. И только после этого выбирается криптографический primitive под конкретное железо, нагрузку и модель угроз.