Шифрование данных пользователя: сравнение AES и ChaCha20

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

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

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

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

AES — блочный шифр. Он обрабатывает данные блоками фиксированного размера: 128 бит, то есть 16 байт. В зависимости от длины ключа AES выполняет 10, 12 или 14 раундов преобразований. Используются ключи длиной 128, 192 или 256 бит. Сам стандарт AES зафиксирован в NIST FIPS 197, но «голый» AES не решает задачу целиком: он описывает шифр, а не безопасный протокол для произвольного файла, сообщения или сетевого потока.

Для практической защиты нужен режим работы. AES-GCM одновременно шифрует данные и проверяет их целостность, поэтому относится к конструкциям AEAD. AES-CBC или AES-CTR сами по себе такой проверки не дают: к ним приходится добавлять отдельный механизм аутентификации, а неправильный порядок операций легко превращается в уязвимость. Именно здесь разработчики спотыкаются чаще всего — не на стойкости AES как математического объекта, а на неверной сборке конструкции вокруг него.

ChaCha20 устроен иначе. Это потоковый шифр из семейства ARX: Addition, Rotation, XOR, то есть сложение, циклический сдвиг и исключающее «или». Он генерирует псевдослучайный поток, который затем комбинируется с открытым текстом операцией XOR. Размер ключа у ChaCha20 — 256 бит, а сама конструкция не использует таблицы подстановок и сложные обращения к памяти.

Но есть важная оговорка: ChaCha20 тоже не проверяет целостность данных сам по себе. В прикладных протоколах обычно используется связка ChaCha20-Poly1305, где Poly1305 отвечает за аутентификацию. Это такая же AEAD-конструкция, как AES-GCM. Поэтому корректнее сравнивать не «AES против ChaCha20» в вакууме, а AES-256-GCM против ChaCha20-Poly1305 либо XChaCha20-Poly1305.

AES и ChaCha20 — это только половина разговора. В реальном приложении важна вся AEAD-конструкция: шифрование, проверка целостности, nonce и то, как библиотека соединяет эти части.

Для пользователя разница выражается вполне конкретно. Разработчик AES-256-GCM должен правильно выбрать режим, организовать работу с nonce, обработать authentication tag и не допустить повторного использования параметров с одним ключом. Разработчик ChaCha20-Poly1305 решает те же задачи на уровне протокола, но получает другую внутреннюю конструкцию и более предсказуемое поведение на процессорах без специального ускорения AES.

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

Производительность в реальных условиях: роль аппаратного ускорения AES

Когда речь заходит о скорости, у AES и ChaCha20 — разные сильные стороны. Результат зависит не от абстрактного рейтинга алгоритмов, а от устройства, операционной системы, библиотеки и размера обрабатываемых сообщений.

У AES есть важное преимущество: современные процессоры часто умеют ускорять его специальными инструкциями. В мире Intel и AMD это семейство AES-NI. На процессорах Apple и многих ARM-устройствах используются криптографические расширения ARMv8, включая аппаратные инструкции для AES. Называть всё это AES-NI некорректно: AES-NI — термин для набора инструкций архитектуры x86, тогда как Apple M3 Pro использует аппаратное ускорение AES через ARMv8 Cryptography Extensions.

По доступным бенчмаркам на Apple M3 Pro без задействованного аппаратного ускорения AES картина выглядит так:

• XChaCha20-Poly1305 выдаёт порядка 4,2 ГБ/с;
• AES-256-GCM в тех же условиях — около 1,8 ГБ/с.

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

Но когда включается аппаратное ускорение AES, расклад меняется. На том же Apple M3 Pro, уже с использованием доступных ARMv8 Cryptography Extensions:

• AES-256-GCM — около 6,4 ГБ/с;
• XChaCha20-Poly1305 — примерно те же 4,2 ГБ/с.

AES не просто догоняет, а уходит вперёд. Это не противоречие предыдущему сравнению, а хороший пример того, насколько сильно результат зависит от платформы. На современном x86-процессоре с AES-NI или на ARM-чипе с криптографическими расширениями AES-GCM способен обрабатывать данные быстрее программной реализации ChaCha20.

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

Отсюда первая практическая мысль: если приложение работает на зоопарке устройств — от свежих MacBook до пятилетних смартфонов, — ChaCha20 даёт более предсказуемую программную производительность. Если же инфраструктура состоит из современных серверов и клиентов с аппаратным ускорением AES, AES-256-GCM часто оказывается быстрее и эффективнее по загрузке CPU.

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

Безопасность и атаки по сторонним каналам: почему ChaCha20 удобнее защищать в программном коде

Скорость — только одна часть уравнения. Если реализация выдаёт секреты через время выполнения или поведение кэша процессора, высокая пропускная способность не особенно радует.

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

Так работают cache-timing-атаки. Они особенно неприятны в виртуализированных средах, облаках и на shared-хостинге, где разные процессы могут делить одно физическое оборудование. Атакующему не обязательно получить доступ к памяти приложения напрямую: иногда достаточно измерять поведение соседнего процесса и собирать статистику.

Современные библиотеки умеют реализовывать AES без таких таблиц — через constant-time-подходы или аппаратные инструкции. В корректной сборке AES-GCM не превращается в уязвимость просто из-за того, что это AES. Проблема возникает, когда старый код, неподходящая сборка или неудачный порт используют небезопасный путь вычислений.

ChaCha20 в этом смысле удобнее. Его базовые операции — сложение слов фиксированной длины, циклические сдвиги и XOR. В них нет таблиц подстановок, адреса которых зависят от секретных данных, и нет необходимости строить реализацию вокруг переменных обращений к памяти. Поэтому ChaCha20 хорошо подходит для программного constant-time-кода на самых разных CPU.

Это не магический иммунитет. Компилятор может неудачно преобразовать код, разработчик может ошибиться в обработке ключа или nonce, а сама система может выдавать секреты через другие каналы — например, по ошибкам, журналам, работе с памятью или энергопотреблению. Но базовая конструкция ChaCha20 снижает количество опасных мест, которые нужно контролировать.

Аппаратно ускоренный AES и аккуратно реализованный ChaCha20 могут быть одинаково надёжными. Разница в том, сколько возможностей для ошибки остаётся до того, как код вообще попадёт в продакшен.

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

При этом нельзя превращать выбор ChaCha20 в маркетинговое обещание. Если ключ хранится в небезопасном месте, seed-фраза попадает в логи, а приложение принимает данные до проверки authentication tag, алгоритм не спасёт. Безопасное шифрование данных на клиенте начинается не с громкого названия, а с полной цепочки: генерация ключа, хранение, nonce, шифрование, проверка целостности, обработка ошибок и обновление библиотек.

Управление nonce и надёжность реализации: от 96-битного стандарта к XChaCha20

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

Nonce — это уникальное значение, которое используется вместе с ключом, чтобы одинаковые сообщения не превращались в одинаковые фрагменты шифротекста. В AEAD-схемах nonce не обязан быть секретным, но он должен быть уникальным для каждого шифрования с одним и тем же ключом. Если повторно использовать его в AES-GCM или ChaCha20-Poly1305, последствия могут быть серьёзными: нарушается конфиденциальность, а в некоторых сценариях под угрозой оказывается и целостность сообщений.

Стандартные AES-GCM и ChaCha20-Poly1305 обычно используют 96-битный, или 12-байтовый, nonce. Это удобный размер для сетевых протоколов. Но разработчику нужно обеспечить уникальность. Можно применять счётчик, составлять nonce из идентификатора соединения и порядкового номера или использовать тщательно спроектированную схему генерации.

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

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

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

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

Критерии выбора для Web3-приложений, VPN и реальных сценариев

Где всё это живёт на практике? Один из самых понятных примеров — WireGuard. В нём используется ChaCha20-Poly1305, и это связано с требованиями самого протокола: он рассчитан на широкий диапазон устройств, от серверов до смартфонов и домашних роутеров. Предсказуемая скорость без обязательной зависимости от аппаратного ускорения AES здесь важнее потенциального преимущества AES на конкретном новом процессоре.

TLS 1.3 и HTTP/3 через QUIC поддерживают оба семейства AEAD-конструкций. В зависимости от платформы, аппаратных возможностей и настроек может использоваться AES-GCM или ChaCha20-Poly1305. В идеальной конфигурации клиент и сервер договариваются автоматически, поэтому пользователь получает подходящий вариант без ручного выбора.

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

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

Поэтому пользователю стоит смотреть не на расплывчатое «военное шифрование AES-256», а на конкретику:

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

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

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

Что выбрать: AES или ChaCha20

У AES и ChaCha20 нет универсального победителя. Есть алгоритм, который лучше подходит конкретной платформе, протоколу и модели хранения данных.

ChaCha20-Poly1305 или XChaCha20-Poly1305 логично рассматривать, если:

• приложение работает на мобильных устройствах, IoT-оборудовании и бюджетных ноутбуках;
• нужна предсказуемая программная производительность без расчёта на аппаратный AES;
• важно снизить риск cache-timing-проблем в собственной реализации;
• шифруются независимые файлы, заметки или резервные копии;
• разработчик хочет использовать длинный nonce XChaCha20 и упростить безопасную случайную генерацию.

AES-256-GCM часто оказывается разумнее, если:

• основная инфраструктура работает на современных процессорах Intel или AMD с AES-NI;
• приложение развёрнуто на ARM-платформах с доступными ARMv8 Cryptography Extensions;
• на первом месте стоит максимальная пропускная способность;
• используемый стек уже хорошо интегрирован с аппаратным ускорением AES;
• требуется соответствие определённым сертификационным или регуляторным требованиям, включая сценарии, где важен FIPS-совместимый стек.

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

И AES-256-GCM, и ChaCha20-Poly1305 остаются криптографически стойкими против прямого перебора при корректно выбранных ключах. Реальные инциденты чаще начинаются не с того, что кто-то «сломал AES» или нашёл практический способ перебрать ChaCha20, а с повторного nonce, слабого пароля, утечки ключа, ошибки в проверке целостности или уязвимой реализации.

Именно поэтому вопрос «aes или chacha20 для защиты данных» нельзя решать одной строкой из таблицы производительности. Сначала нужно определить платформы, размеры сообщений, модель угроз и жизненный цикл ключей. Затем — выбрать AEAD-конструкцию, проверить библиотеку и убедиться, что аппаратное ускорение действительно используется там, где на него рассчитывают.

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