Протоколы шифрования данных: топ стандартов под разные задачи

У слова «шифрование» в Web3 до сих пор слишком удобная репутация: будто достаточно добавить AES-256, написать в документации «military-grade security» — и данные уже защищены от всего, включая квантовый компьютер, баги в коде и разработчика, который случайно залил ключ в публичный репозиторий. На практике это так не работает.

AES-256 защищает данные в состоянии покоя, TLS 1.3 — сетевое соединение, ChaCha20-Poly1305 — поток данных там, где аппаратное ускорение AES недоступно, а постквантовые стандарты NIST FIPS 203, 204 и 205 решают уже другую задачу: подготовку криптографической инфраструктуры к угрозам, которых сегодня в массовом масштабе еще нет. Смешать все эти механизмы в одну рекламную кашу — простой способ получить красивый whitepaper и неясную модель угроз.

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

Сначала разделим шифрование, аутентификацию и транспорт

В разговорной речи протоколами шифрования называют почти все, что связано с защитой данных. Технически это разные уровни.

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

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

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

Постквантовые FIPS 203, 204 и 205 — семейство стандартов, направленных на замену или дополнение уязвимых к квантовым атакам механизмов открытого ключа. Это не «новый AES». У них другая математическая основа и другой участок криптографического стека.

Шифр защищает содержимое, протокол — взаимодействие, а ключи по-прежнему остаются тем местом, где обычно заканчивается вся магия.

Для практической оценки протокола я смотрю не на громкость маркетинга, а на пять вопросов:

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

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

AES-256: базовый стандарт, а не универсальная религия

AES остается фундаментом для защиты данных в хранилищах, резервных копиях, базах данных, аппаратных модулях безопасности и прикладных системах. Стандарт AES, утвержденный NIST в FIPS 197, использует блок размером 128 бит и поддерживает ключи длиной 128, 192 и 256 бит. Версия AES-256 наиболее известна в корпоративных и криптографически чувствительных сценариях, но ее популярность не означает, что остальные варианты внезапно стали бесполезными.

Ключ длиной 256 бит увеличивает запас прочности против перебора. Однако реальная безопасность системы редко ломается об перебор ключа. Гораздо чаще проблемы возникают из-за повторного использования nonce, неправильного режима шифрования, слабой генерации случайных чисел, хранения ключей рядом с зашифрованными данными или отсутствия аутентификации.

AES-256 в режиме CBC без отдельного механизма контроля целостности — уже не современная рекомендация для нового проекта. Шифрование и аутентификация должны быть связаны через AEAD-режимы, например AES-GCM. В противном случае разработчик получает две независимые задачи и легко решает только половину одной из них.

Для Web3-инфраструктуры AES-256 обычно появляется в нескольких местах:

1. Хранение резервных копий и секретов.

Приватные ключи, seed-фразы, конфигурации валидаторов и архивы могут шифроваться перед записью на диск или в облачное хранилище.

2. Защита данных вне блокчейна.

Сам блокчейн прозрачен по конструкции: данные, записанные в публичный реестр, нельзя сделать приватными простым добавлением AES. Шифрование применяется до публикации или в связанных off-chain системах.

3. Защита состояния приложений.

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

4. Аппаратные и серверные хранилища.

AES хорошо поддерживается современными процессорами и специализированными модулями, что делает его удобным для больших объемов данных.

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

AES-128, AES-192 и AES-256 в прикладном выборе

В большинстве новых систем вопрос стоит не как «AES-256 или ничего», а как «какой AEAD-режим, где лежит ключ и что произойдет после его компрометации». На этом уровне и находится реальная безопасность.

ChaCha20-Poly1305: когда скорость важнее аппаратного ускорения AES

ChaCha20-Poly1305 — один из наиболее практичных криптографических протоколов защиты данных для устройств, где нет специализированных инструкций ускорения AES. Связка описана в RFC 8439 и относится к AEAD, то есть одновременно обеспечивает конфиденциальность и аутентифицированную целостность.

Почему это важно? AES на современном сервере с аппаратной поддержкой может работать чрезвычайно быстро. Но мир не состоит только из серверов с предсказуемым набором инструкций. В мобильных устройствах, малых системах, некоторых виртуализированных окружениях и специализированном железе ChaCha20 способен дать более стабильную производительность и не требует сложной реализации таблиц или привязки к конкретным аппаратным ускорителям.

У ChaCha20 есть потоковая структура: данные обрабатываются через генерацию псевдослучайного потока, который комбинируется с открытым текстом. Poly1305 добавляет тег аутентификации. Получатель проверяет тег и только после этого принимает сообщение как достоверное. Это не косметическая надстройка, а защита от подмены и повреждения трафика.

В сетевых протоколах выбор между AES-GCM и ChaCha20-Poly1305 часто зависит от конкретного оборудования:

• на процессорах с аппаратным ускорением AES-GCM может быть быстрее;
• на устройствах без такого ускорения ChaCha20-Poly1305 часто выглядит рациональнее;
• оба варианта требуют корректной работы с nonce;
• ни один из них не спасает систему, если ключи украдены или случайные числа генерируются предсказуемо.

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

TLS 1.3: защищенный канал, но не приватность по умолчанию

TLS 1.3, опубликованный IETF в RFC 8446 в августе 2018 года, стал стандартом для защиты сетевых соединений. Он сократил базовое установление соединения до одного кругового пути — 1-RTT — и убрал ряд устаревших криптографических механизмов, включая статическое шифрование RSA, RC4 и режим CBC.

Это не просто косметическая чистка списка алгоритмов. Старые версии TLS тащили за собой исторический груз: совместимость с устаревшими системами, неоднозначные режимы, сложные настройки и большее пространство для downgrade-атак. TLS 1.3 уменьшил количество допустимых комбинаций и сделал протокол более жестким по умолчанию. Для безопасности это обычно полезно: чем меньше экзотики в конфигурации, тем меньше шансов, что администратор включит ее ради одного древнего клиента, а потом забудет выключить.

Базовая схема выглядит так:

1. клиент и сервер договариваются о параметрах соединения;

2. стороны выполняют обмен, позволяющий вывести общий секрет;

3. сервер доказывает владение соответствующим ключом через сертификат и подпись;

4. дальнейший трафик шифруется симметричным AEAD-алгоритмом;

5. пакеты проверяются на целостность и отбрасываются при ошибке аутентификации.

TLS 1.3 поддерживает режим 0-RTT для возобновления сессии. Он уменьшает задержку, но имеет цену: ранние данные могут быть уязвимы к повторной отправке, поэтому такой режим нельзя бездумно применять к операциям, меняющим состояние. Отправить запрос на чтение баланса и отправить транзакцию — не одно и то же, даже если оба действия технически помещаются в HTTPS-соединение.

В Web3 TLS 1.3 защищает:

• соединения кошелька с RPC-провайдером;
• доступ к API биржи или DeFi-сервиса;
• панели управления узлами и валидаторами;
• передачу данных между микросервисами;
• загрузку фронтенда и взаимодействие с backend-компонентами.

Но TLS не скрывает все метаданные. Он обычно защищает содержимое канала от сетевого наблюдателя, однако сам факт соединения, IP-адрес, время активности, объемы трафика и некоторые характеристики маршрута могут оставаться видимыми. Кроме того, конечная точка расшифровывает данные. Если RPC-провайдер видит ваш запрос, TLS не превращает его в слепого ретранслятора.

TLS защищает дорогу между кошельком и RPC. Он не делает RPC-провайдера незрячим, честным и телепатически неспособным анализировать ваш поток запросов.

Отдельная оговорка касается транспорта. TLS 1.3 предназначен прежде всего для потоковых соединений вроде TCP. Для UDP и datagram-трафика применяется DTLS, а не TLS в его обычной форме. Поэтому фраза «TLS 1.3 защищает все сетевые соединения» звучит эффектно, но технически слишком грубо.

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

Сквозное шифрование часто используют как синоним «соединение защищено». Это разные модели.

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

Это требует не просто включить AES или ChaCha20. Нужны:

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

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

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

Постквантовая криптография: стандарты уже утверждены, миграция еще нет

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

• FIPS 203 — ML-KEM, механизм инкапсуляции ключей;
• FIPS 204 — ML-DSA, схема цифровой подписи;
• FIPS 205 — SLH-DSA, альтернативная схема цифровой подписи на другой математической основе.

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

Постквантовая угроза касается прежде всего криптографии с открытым ключом. Квантовый алгоритм Шора в теории создает угрозу широко применяемым схемам, связанным с факторизацией и дискретным логарифмированием. Это не означает, что RSA или ECDSA уже взломаны. Достаточного универсального квантового компьютера для такой атаки в массовой эксплуатации сегодня нет. Но данные могут собираться заранее: зашифрованный трафик сохраняется сейчас, а расшифровка откладывается до появления подходящей вычислительной мощности. Такой сценарий обычно называют harvest now, decrypt later.

Для Web3 особенно чувствительна проблема подписей. В публичных сетях адрес и транзакционная активность могут раскрывать информацию, позволяющую атаковать устаревшую схему после публикации открытого ключа. Конкретная уязвимость зависит от архитектуры сети, типа адресов, правил раскрытия ключа и времени, необходимого для проведения атаки. Универсального рецепта «перейдите на алгоритм X» здесь нет.

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

Как работает ML-KEM и почему это не еще один AES

FIPS 203 определяет ML-KEM — механизм инкапсуляции ключей, основанный на семействе CRYSTALS-Kyber. Его назначение — позволить двум сторонам получить общий секрет через открытый канал, причем атакующий, наблюдающий обмен, не должен суметь восстановить этот секрет.

В упрощенной модели участник генерирует пару ключей:

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

Сам ML-KEM не шифрует весь большой файл или поток транзакций. Он решает задачу согласования ключа. Для объемных данных после установления общего секрета по-прежнему используются быстрые симметричные алгоритмы вроде AES-GCM или ChaCha20-Poly1305.

FIPS 203 определяет три набора параметров:

• ML-KEM-512;
• ML-KEM-768;
• ML-KEM-1024.

Число в названии не следует воспринимать как длину ключа в битах или как прямой аналог AES-256. Это обозначение параметрического уровня безопасности внутри стандарта. Сравнивать ML-KEM-768 и AES-256 напрямую — примерно как сравнивать двигатель грузовика с замком на банковском сейфе: оба нужны для надежной системы, но отвечают на разные вопросы.

Что меняется в инфраструктуре

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

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

В классической криптографии подпись может занимать относительно небольшой объем и легко помещаться в существующий формат транзакции. Постквантовые схемы способны изменить эту арифметику. Если транзакция становится больше, растут требования к пропускной способности сети и стоимости хранения. Для L2 и rollup-систем добавляется отдельный вопрос: как новые подписи и доказательства повлияют на публикацию данных и верификацию состояния.

Здесь и появляется главный скрытый счет. Миграция не приносит немедленной доходности, не увеличивает TVL и не продается пользователю как красивый фарминг. Она просто предотвращает потенциально дорогую замену криптографического фундамента в будущем. Венчурному маркетингу скучно. Инфраструктуре — нет.

ML-DSA и SLH-DSA: подписи с разными компромиссами

FIPS 204 и FIPS 205 предназначены для цифровых подписей, а не для инкапсуляции ключей.

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

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

Для оценки постквантовой подписи в Web3 придется смотреть не только на математическую стойкость:

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

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

Как сравнивать лучшие стандарты шифрования по задаче

Универсального рейтинга протоколов шифрования данных нет. Есть корректное соответствие между механизмом и угрозой.

Из таблицы видно главное: AES-256 и ML-KEM нельзя ставить в один ряд как конкурирующие продукты. Они работают на разных уровнях. Сравнивать их можно только внутри архитектуры, где один отвечает за симметричное шифрование данных, а второй — за безопасный обмен ключами.

Почему криптографический протокол ломается не в математике

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

Повторное использование nonce

AEAD-алгоритмы требуют уникальности nonce для заданного ключа. Повтор может привести к раскрытию отношений между сообщениями и нарушению целостности. Это не тот класс ошибок, который лечится переходом с AES-128 на AES-256. Если генератор идентификаторов устроен неправильно, более длинный ключ просто будет участвовать в более дорогой катастрофе.

Ключи в логах и переменных окружения

Секрет может утечь через debug-лог, дамп памяти, резервную копию CI/CD, ошибочно настроенный мониторинг или образ контейнера. В Web3 это особенно болезненно: украденный приватный ключ не требует судебной процедуры, чтобы активы начали миграцию на другой адрес.

Неверная модель доверия

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

Отсутствие ротации

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

Устаревшие режимы ради совместимости

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

Доверие к whitepaper вместо аудита реализации

Whitepaper описывает намерение. Атакующий работает с кодом, зависимостями, оракулами, правами администратора и маршрутом вывода средств. В DeFi протокол может использовать прекрасную криптографию и при этом потерять TVL из-за ошибки в смарт-контракте, некорректного контроля доступа или манипуляции ценовым источником.

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

Что выбирать для Web3-инфраструктуры сейчас

Для нового проекта разумнее собирать стек по слоям, а не выбирать один «лучший стандарт шифрования»:

1. Для данных в хранилище — использовать современный AEAD-подход на базе AES или ChaCha20, а ключи держать отдельно от данных и приложения, которое ими пользуется.

2. Для сетевых соединений — включать TLS 1.3 там, где используется потоковый транспорт, и не переносить его бездумно на UDP-сценарии, где нужен DTLS или иной специализированный механизм.

3. Для мобильных и слабых устройств — рассматривать ChaCha20-Poly1305 как практичную альтернативу при отсутствии аппаратного ускорения AES.

4. Для обмена ключами с длинным сроком жизни данных — проектировать криптографическую гибкость, чтобы позднее добавить ML-KEM без полной перестройки протокола.

5. Для подписей — отдельно анализировать ML-DSA и SLH-DSA, учитывая размер транзакций, производительность проверки и обновление адресной модели.

6. Для управления средствами — не сводить защиту к одному приватному ключу: использовать мультиподпись, аппаратные кошельки, разграничение ролей и сценарии аварийного восстановления.

7. Для приватности транзакций — оценивать не только шифрование содержимого, но и утечки по времени, суммам, адресам, RPC-запросам и графу взаимодействий.

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

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

Это уже не чистая криптография. Это экономика протокола.

Вердикт

Лучшие протоколы шифрования данных не конкурируют за один пьедестал. AES-256 остается сильным и практичным выбором для хранения чувствительной информации, если рядом есть корректный AEAD-режим и нормальное управление ключами. ChaCha20-Poly1305 закрывает ту же прикладную потребность в другом аппаратном профиле и особенно уместен там, где AES не получает ускорения. TLS 1.3 — базовый стандарт защищенного сетевого канала, но не замена сквозному шифрованию и не индульгенция для RPC-провайдера.

FIPS 203, 204 и 205 — уже не исследовательская экзотика, а стандартизированный фундамент постквантовой миграции. Но готовый стандарт не равен готовой интеграции. Web3-протоколам предстоит пересмотреть форматы подписей, размер транзакций, аппаратные кошельки, мультиподпись, резервное копирование и процедуру обновления адресов.

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

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