Безопасность и шифрование данных: выбор криптографических схем
В Web3-проекте слово «шифрование» часто используют как универсальную наклейку на всё сразу: кошелёк подписывает транзакции, сервер хранит профили, роллап доказывает корректность вычислений — значит, данные якобы защищены.
На практике это три разных юзкейса с разными рисками. И ошибка обычно появляется не в формуле алгоритма, а на стыке: команда берёт удобную библиотеку, оставляет старую схему подписи «на потом», а приватность пользователя пытается решить доказательством, которое не рассчитано на такой объём проверок.
В 2026 году выбирать криптографические методы защиты информации приходится сразу в двух временных горизонтах. Первый — сегодняшняя эксплуатация: скорость, стоимость верификации, размер ключей, онбординг команды и пользователей. Второй — данные, которые должны оставаться секретными годы: документы, медицинские записи, коммерческие условия, приватные переписки, внутренние ключи инфраструктуры. Для них вопрос постквантовой устойчивости уже не академический.
Я обычно начинаю разбор не с вопроса «какой алгоритм самый надёжный», а с другого: что именно система обязана скрывать, что должна подтверждать публично и сколько лет это свойство должно жить. После этого выбор заметно упрощается.
Хорошая криптография не та, которую сложнее всего объяснить на созвоне. Хорошая — та, чьи границы команда понимает и не обходит в первом же релизе.
Шифрование, подпись и доказательство: три задачи, которые не стоит смешивать
У пользователя есть понятное ожидание: если приложение говорит о приватности, никто не увидит его данные и не сможет действовать от его имени. Реальность устроена чуть строже. Для этого нужны отдельные механизмы.
Шифрование скрывает содержимое. Например, приложение шифрует резервную копию, сообщение или файл так, чтобы прочитать его мог только владелец нужного ключа. Здесь уместно различать симметричное и асимметричное шифрование.
- При симметричном шифровании один секретный ключ шифрует и расшифровывает данные. Это рабочая лошадка для больших объёмов: файлов, баз данных, вложений, локального хранилища.
- При асимметричном шифровании есть открытый ключ для получения секрета и закрытый — для его раскрытия. Оно удобнее там, где стороны ещё не договорились об общем ключе, но обычно применяется не для шифрования гигабайтов данных, а для безопасной передачи сеансового ключа.
- Цифровая подпись не прячет сообщение. Она подтверждает, что действие авторизовал держатель закрытого ключа и что данные по пути не изменились.
- Доказательство с нулевым разглашением позволяет показать корректность утверждения без раскрытия исходных данных. «У меня достаточно средств», «я прошёл проверку возраста», «переход состояния роллапа посчитан верно» — но без публикации баланса, даты рождения или внутренней логики вычисления.
Это звучит очевидно, пока не открываешь интерфейс типичного dApp. Там кнопка «Подключить кошелёк» может означать только чтение публичного адреса, а следующая кнопка — уже подпись потенциально опасного сообщения. В другом продукте «private transaction» скрывает сумму, но оставляет видимыми другие метаданные. В третьем «end-to-end encryption» защищает текст сообщения, однако сервер всё равно видит, кто, когда и как часто общается.
Поэтому безопасность шифрования данных — не галочка «используем криптографию». Это карта свойств системы: что скрываем, кому доверяем, где лежат ключи, кто может восстановить доступ и что увидит наблюдатель блокчейна.
Постквантовый переход: не повод ломать всё завтра, но повод перестать откладывать архитектуру
В августе 2024 года NIST утвердил первые стандарты постквантовой криптографии. Это важная точка: индустрия получила не просто перспективные кандидаты, а базовые стандарты, вокруг которых можно строить дорожные карты.
| Стандарт NIST | Алгоритм | Роль в системе | Практический смысл |
|---|---|---|---|
| FIPS 203 | ML-KEM | Установка или инкапсуляция ключа | Помогает двум сторонам получить общий секрет для дальнейшего симметричного шифрования |
| FIPS 204 | ML-DSA | Цифровая подпись | Подтверждает авторство и целостность сообщений, транзакций, обновлений |
| FIPS 205 | SLH-DSA | Подпись на основе хеш-функций | Альтернативный консервативный путь для сценариев, где ценят минимальное число допущений |
Самая полезная продуктовая мысль здесь простая: не нужно пытаться шифровать пользовательские данные «постквантовым алгоритмом вместо всего остального». Обычно схема собирается слоями. Асимметричный механизм нужен, чтобы безопасно договориться о секрете; сами данные затем быстрее и дешевле обрабатываются симметричным шифром.
Для Web3 это особенно заметно. Если приложение хранит зашифрованные заметки, приватные документы DAO или резервные копии аккаунта, основной объём данных логично защищать симметрично. А вот этап выдачи и обновления ключей, подписи администраторов, доверие к устройству и восстановление доступа потребуют отдельного решения.
Постквантовая угроза не означает, что завтра исчезнет вся классическая криптография. Но действует неприятный сценарий «собрать сейчас — расшифровать потом». Если данные перехватывают сегодня, а их ценность сохраняется десять лет, будущий вычислительный прогресс становится уже сегодняшним риском.
Я бы разделил решения на три группы.
1. Системы с короткой жизнью данных. Одноразовый сеансовый секрет, временный токен, недолгая сессия. Здесь важнее не впадать в миграционную панику, а быстро менять ключи и не копить логи с секретами.
2. Данные с долгой конфиденциальностью. Персональные документы, корпоративная переписка, seed-фразы в зашифрованном бэкапе, сведения о бенефициарах. Для них постквантовая дорожная карта нужна уже на уровне архитектуры: криптографический слой должен быть заменяемым, а не зашитым в каждый смарт-контракт, мобильный клиент и бэкенд.
3. Публичные блокчейн-подписи. Здесь миграция сложнее всего. Смена алгоритма подписи затрагивает адреса, кошельки, аппаратные устройства, формат транзакций и консенсусные правила. Нельзя просто «обновить библиотеку» и считать задачу закрытой.
Главный выигрыш сейчас — криптографическая гибкость. Когда алгоритм, формат ключа и версия схемы явно записаны в протоколе, их можно обновить без болезненного переселения всех пользователей. Если же приложение предполагает один вечный тип ключа, будущая миграция почти гарантированно станет дорогим UX-проектом с потерянными аккаунтами.
Длина ключа и криптопериод: безопасность ломается в календаре чаще, чем в алгоритме
Криптография стареет не только из-за найденных атак. Стареют ключи, реализации, зависимости, доступы бывших сотрудников и резервные копии, о которых все забыли. Поэтому у защищённой системы должен быть не «ключ навсегда», а понятный жизненный цикл: выпуск, использование, ротация, отзыв, уничтожение.
NIST в SP 800-57 рекомендует ограничивать активное использование симметричных ключей шифрования данных сроком в один-два года. Для закрытых ключей асимметричной подписи ориентир составляет один-три года. Это не таймер, который обязательно должен погасить продукт ровно в полночь. Это напоминание о дисциплине: чем дольше ключ живёт и чем больше операций им подписано или зашифровано, тем выше цена его утечки.
В проекте третьей версии Agreed Cryptographic Mechanisms ENISA заметен тот же сдвиг: устаревшие механизмы не просто получают ярлык «legacy», а описываются как допустимые лишь до ограниченного горизонта. Для части схем фигурирует отметка A[2033] — то есть ориентир окончания приемлемого использования к концу 2033 года.
Для команды это полезнее читать не как список запретов, а как бэклог миграции. В частности, из перечня допустимых механизмов исключаются:
- RSA с ключом короче 3000 бит;
- хеш-функции SHA-224 и SHA-512/224;
- старые композиции MAC-then-Encrypt и Encrypt-and-MAC.
Последний пункт особенно поучителен. Можно взять сильный алгоритм шифрования, но собрать вокруг него неверный порядок проверки целостности — и получить систему, где ошибки обработки пакета становятся каналом атаки. В криптографии «какой шифр» — только половина вопроса. Вторая половина — как приложение связывает шифрование, проверку целостности, метаданные и обработку ошибок.
Отдельно часто вспоминают AES-256 как обязательный ответ на квантовую угрозу. Это слишком грубое упрощение. ENISA указывает, что немедленно удваивать длину симметричных ключей не требуется: достаточным ориентиром для защиты от квантовых рисков считается длина ключа не менее 192 бит. У AES-256 есть хорошие причины для выбора, особенно в долгоживущих системах, но превращать его в магический ритуал не стоит.
Где ключевая боль ощущается пользователем
Пользователь не видит криптопериод. Он видит другое: после обновления приложения не открывается старый зашифрованный файл; новый телефон не может восстановить доступ; админ DAO потерял устройство, и вся схема мультиподписи застыла.
Поэтому ротацию ключей нужно проектировать как UX, а не как ночную операцию DevOps-команды:
- хранить версию криптографической схемы рядом с зашифрованным объектом;
- давать клиенту возможность расшифровать старые данные прежним ключом и тут же перешифровать их новым;
- заранее определить, что происходит при компрометации ключа;
- не смешивать ключ подписи транзакций с ключом, которым шифруется пользовательский контент;
- тестировать восстановление доступа так же регулярно, как отправку транзакции.
Самая дорогая утечка — не та, о которой узнали из аудита, а та, после которой оказывается: никто не понимает, какие данные были зашифрованы этим ключом.
Groth16, PLONK и Bulletproofs: выбор ZK-схемы начинается с цены проверки
Доказательства с нулевым разглашением часто продают как универсальную кнопку приватности и масштабирования. Нажимаем — и блокчейн верит расчёту, не видя исходных данных. Это действительно мощный подход, но UX и экономика зависят от выбранной схемы очень заметно.
Я бы не выбирал между Groth16, PLONK и Bulletproofs по принципу «что сейчас чаще звучит в презентациях». Сначала стоит ответить: где происходит верификация, как часто меняется вычислительный контур, кто готовит доказательства, сколько стоит проверка в целевой сети и может ли проект принять доверенную настройку.
| Параметр | Groth16 | PLONK | Bulletproofs |
|---|---|---|---|
| Размер доказательства | Очень малый: три элемента группы | Обычно больше, чем у Groth16 | Зависит от задачи, не даёт компактности Groth16 в сложных сценариях |
| Скорость верификации | Очень высокая | Практичная для широкого класса приложений | Растёт линейно с размером задачи, O(n) |
| Доверенная настройка | Нужна отдельно для каждого контура вычислений | Универсальная, может обновляться | Не нужна |
| Гибкость при изменении логики | Низкая: новый контур — новая настройка | Выше: подходит для развивающихся схем | Хороша там, где ценнее отсутствие настройки, чем дешёвая проверка |
| Типичный продуктовый компромисс | Минимум данных и стоимости при стабильной логике | Баланс между гибкостью и удобством эксплуатации | Простота доверительной модели ценой более тяжёлой верификации |
Groth16: быстрый результат, если логика уже устоялась
Groth16 остаётся сильным выбором для сценариев, где критичны маленькое доказательство и быстрая верификация. В блокчейне это часто прямо превращается в более предсказуемую стоимость операции. Если контур вычислений стабилен — например, проверка конкретного правила приватного перевода — компактность Groth16 выглядит очень убедительно.
Но есть цена: trusted setup, или доверенная настройка, нужна для каждого отдельного circuit. Если схема меняется, настройку придётся повторять. Для продукта, который ещё каждую неделю корректирует бизнес-правила, это создаёт трение: разработчики не просто выкатывают новую версию логики, а заново проходят чувствительную процедуру подготовки параметров.
Риск не в том, что trusted setup автоматически делает систему плохой. Риск в том, что команда относится к ней как к технической формальности. Для пользователя же разница принципиальна: если процедура была скомпрометирована, возможны нарушения экономической целостности системы, которые интерфейс никак не покажет.
PLONK: когда продукт ещё будет меняться
PLONK использует универсальную обновляемую настройку. Это более комфортная база для приложения, где контуры вычислений будут расти: добавятся новые правила доступа, лимиты, типы активов, варианты доказательств.
В практическом смысле PLONK снижает цену итераций. Мне не нужно объяснять команде, почему изменение одного условия в приватном расчёте может тянуть за собой отдельный церемониальный процесс. Но это не означает, что PLONK автоматически лучше. Верификатор, инструменты разработки, совместимость с целевой сетью, время генерации доказательства на пользовательском устройстве — всё это надо измерять на реальном контуре, а не на абстрактном бенчмарке.
Если доказательство строится в браузере на среднем ноутбуке или телефоне, победитель по газу может проиграть по онбордингу. Пользователь просто увидит вечный спиннер на кнопке «Подтвердить приватную операцию» и уйдёт до того, как оценит изящество протокола.
Bulletproofs: без настройки, но не без цены
Bulletproofs привлекательны тем, что не требуют доверенной настройки. Для некоторых задач это фундаментальное преимущество: меньше церемоний, меньше организационного доверия, проще объяснить модель безопасности аудитору и сообществу.
Но отсутствие setup не означает бесплатную масштабируемость. Верификация Bulletproofs имеет линейную сложность O(n). По мере роста сложности доказуемого утверждения растёт и нагрузка на проверяющего. Для тяжёлой логики, которую нужно массово верифицировать прямо в сети, это может стать плохим продуктовым выбором.
Я бы смотрел на Bulletproofs прежде всего там, где доказательство сравнительно компактно по смыслу, а отказ от доверенной настройки ценнее, чем экстремально дешёвая проверка: например, для отдельных проверок диапазона или более ограниченных приватных утверждений. Превращать их в «универсальный заменитель всех SNARK-схем» не нужно.
Шифр для данных: почему старый алгоритм в репозитории — это не исторический артефакт
Вопрос выбора симметричного алгоритма выглядит скучнее, чем ZK-протоколы, но именно здесь часто лежат пользовательские данные. База с профилями, локальный кэш кошелька, зашифрованные вложения, корпоративный архив — всё это обычно не требует доказательства с нулевым разглашением. Ему требуется корректное, быстрое и поддерживаемое шифрование.
В российском контуре стоит не путать исторически распространённый ГОСТ 28147-89 с актуальным стандартом. Он был окончательно заменён ГОСТ 34.12-2018. В действующем наборе блочных шифров закреплены «Кузнечик» с размером блока 128 бит и «Магма» с блоком 64 бита.
Размер блока — не маркетинговая цифра. Он влияет на уместность схемы в современных системах и объёмах обработки. Если проект работает с новыми потоками данных и рассчитан на долгую эксплуатацию, нельзя выбирать алгоритм по принципу «он уже есть в старом внутреннем сервисе». Нужны актуальная библиотека, понятный режим работы, проверка целостности и нормальная процедура управления ключами.
Для Web3-приложения я бы раскладывал задачу так:
1. Контент пользователя шифруем отдельно от блокчейна. Публикация ciphertext в децентрализованном хранилище может быть разумной, но блокчейн или хранилище не должны становиться местом, где лежит ключ расшифрования.
2. Ключи контента не делаем производными от одного кошелёчного секрета без продуманного восстановления. Пользователь может сменить кошелёк, потерять устройство или использовать аппаратный ключ, который вообще не предназначен для постоянного шифрования файлов.
3. Метаданные считаем данными. Сквозное шифрование в Web3 защищает содержание, но адреса, время операций, размер объектов и связи между аккаунтами могут остаться наблюдаемыми. Называть такую систему полностью анонимной было бы нечестно.
4. Подпись не выдаём за шифрование. Подписанное сообщение может быть публично читаемым. Подпись подтверждает волю пользователя, но не скрывает текст.
5. Проверяем отказоустойчивость не на демо-аккаунте. Нужен сценарий: пользователь потерял один фактор доступа, один участник мультиподписи недоступен, старый ключ отозван. Если продукт не может объяснить путь восстановления без чтения исходного кода, бесшовности здесь нет.
Что выбирать в реальном Web3-проекте
Если нужен короткий вердикт без маркетингового шума, он такой: не существует одной криптографической схемы, которая одновременно идеально шифрует данные, подтверждает действия, скрывает транзакции, выдерживает будущую миграцию и не усложняет интерфейс.
Для шифрования пользовательского контента базовой конструкцией остаётся быстрый симметричный слой с отдельным управлением ключами. Для безопасной передачи или согласования секретов и для подписей нужно заранее закладывать путь к постквантовым стандартам NIST: ML-KEM, ML-DSA и, где уместно по модели риска, SLH-DSA. Не обязательно немедленно переписывать весь стек, но уже обязательно перестать проектировать криптографию как неизменяемую часть продукта.
Для ZK-логики выбор выглядит прагматично:
- берите Groth16, когда контур стабилен, критичны компактность доказательства и быстрая проверка;
- смотрите на PLONK, когда продукт будет часто менять правила и вам нужна более удобная модель настройки;
- используйте Bulletproofs, когда отсутствие доверенной настройки перевешивает стоимость линейной верификации и задача не раздувается до тяжёлого универсального вычисления.
И ещё одна оговорка, которую я бы вынес прямо в спецификацию. Криптографический алгоритм не компенсирует плохой UX. Если пользователь не понимает, что подписывает, не может восстановить доступ и не видит, какие данные уходят в публичную сеть, приложение остаётся небезопасным для него — даже при безупречной математике внутри.
Выбирать стоит не самую модную схему, а ту, чьи ограничения команда готова честно принять, измерить и объяснить. В приватности это и есть первая линия защиты.
