Симметричное и асимметричное шифрование: в чём разница и что выбрать в 2026 году

Симметричное и асимметричное шифрование: ключевое различие

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

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

В рабочей инфраструктуре 2026 года почти всегда встречается гибрид: TLS, SSH, IPsec, WireGuard и корпоративные VPN согласуют сессионный ключ асимметричной схемой, а полезную нагрузку шифруют симметричной. Поэтому выбор редко звучит как «или-или», чаще это распределение ролей: асимметрика отвечает за ключи и подписи, симметрика за данные.

Как работает симметричное шифрование: один ключ для всех

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

Узкое место одно, зато принципиальное: доставка ключа. Канал, по которому ключ попадает к получателю, сам должен быть защищён. Второе ограничение - масштаб. Если n участников обмениваются данными попарно, потребуется n(n-1)/2 ключей: для 10 человек 45, для 100 человек 4950, для 1000 человек почти 500 тысяч. Ротация такого набора превращается в отдельный проект.

Сильные стороны: скорость, минимальный оверхед, работа с большими объёмами. Одно ядро современного CPU шифрует гигабиты в секунду, поэтому диски, бэкапы, базы данных и видеопотоки защищают именно симметрикой. Режимы выбирают под задачу: GCM даёт шифрование с аутентификацией и 128-битный тег; XTS применяют для дисков, где нужны два ключа и отсутствие расширения данных; CBC остаётся в legacy-системах и требует отдельного HMAC; CTR работает как потоковый режим и тоже нуждается в MAC.

Ломает симметрику не математика, а режим использования. Повтор nonce или IV с одним ключом в GCM и ChaCha20-Poly1305 раскрывает XOR двух открытых текстов и позволяет подделать тег. ECB не применяют вообще: одинаковые блоки открытого текста дают одинаковые блоки шифротекста, и структура документа или изображения читается без ключа.

Примеры алгоритмов симметричного шифрования: AES и ChaCha20

AES принят NIST в 2001 году (FIPS 197), это блочный шифр с блоком 128 бит и ключом 128, 192 или 256 бит. С 2010 года в серверные x86-процессоры встроено ускорение AES-NI, в ARMv8 есть аналогичные криптоинструкции, что даёт 1-3 ГБ/с на ядро в режиме GCM. AES-256 входит в требования для данных с длительным сроком хранения и в стандарты госсектора.

ChaCha20 создан Дэниелом Бернштейном в 2008 году, это потоковый шифр с 256-битным ключом и 96-битным nonce, который в паре с MAC Poly1305 образует AEAD-схему. Он работает в TLS 1.3 (набор TLS_CHACHA20_POLY1305_SHA256), в WireGuard и в OpenSSH. Без аппаратного AES на 32-битных ARM и встраиваемых платформах ChaCha20 обгоняет AES в разы, а на сервере с AES-NI картина обратная.

Выбор между ними определяется железом: там, где есть AES-NI или ARM-криптоинструкции, берут AES-GCM, на устройствах без ускорения и в мобильных клиентах - ChaCha20-Poly1305. Оба алгоритма стойкие, разница в производительности на конкретной платформе. Длины ключей, скорости и поддержка в библиотеках собраны в обзоре алгоритмов шифрования от AES до постквантовых схем.

Как работает асимметричное шифрование: пара ключей

Каждый участник генерирует пару ключей. Приватный ключ не покидает устройство, публичный свободно публикуется: в сертификате, в файле authorized_keys, в DNS-записи. Математическая связь между ключами есть, но вычислить приватный из публичного за разумное время нельзя. У RSA стойкость опирается на сложность факторизации больших чисел, у ECC - на задачу дискретного логарифмирования в группе точек эллиптической кривой.

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

Ограничения структурные. Скорость ниже симметрики на три-четыре порядка. Размер ключей и подписей больше. Объём сообщения лимитирован: RSA-2048 с OAEP и SHA-256 шифрует примерно 190 байт за операцию, поэтому напрямую асимметрикой данные не шифруют.

Примеры алгоритмов асимметричного шифрования: RSA и ECC

RSA предложен в 1977 году и до сих пор поддерживается практически везде: в сертификатах X.509, S/MIME, старых API и аппаратных токенах. Стойкость зависит от длины ключа, по NIST SP 800-57: 2048 бит дают около 112 бит стойкости, 3072 бита 128 бит, 4096 бит порядка 140 бит. Генерация подписи RSA-4096 в 6-8 раз медленнее, чем RSA-2048, а проверка идёт быстро за счёт открытой экспоненты 65537.

ECC даёт ту же стойкость при коротких ключах: 256-битная кривая эквивалентна 3072-битному RSA, 384-битная - 7680-битному. Меньше ключ, меньше вычислительная нагрузка, компактнее подписи и сертификаты. В новых системах используют X25519 для обмена ключами, Ed25519 для подписей (RFC 8032) и P-256 (secp256r1) для совместимости с X.509. Брать нестандартные кривые без отдельного аудита нельзя.

Для проектов, которые стартуют в 2026 году, разумный выбор - Ed25519 и X25519. RSA остаётся там, где нужна максимальная широта поддержки: legacy-оборудование, старые клиенты, регуляторные требования с явно прописанными алгоритмами.

Обмен ключами: как симметричное и асимметричное шифрование работают вместе

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

Современный вариант - ECDHE на кривой X25519 или P-256. В TLS 1.3 рукопожатие занимает одно RTT: клиент присылает список шифров и свою ключевую долю, сервер отвечает своей, стороны выводят ключи трафика через HKDF. В дата-центре это 1-3 мс, через публичный интернет 30-100 мс и больше. Дальше трафик идёт симметричным шифром на гигабитах.

Схема даёт forward secrecy: компрометация долговременного приватного ключа сервера не позволяет расшифровать ранее записанный трафик, потому что сессионные ключи уже уничтожены. В TLS 1.2 режим с передачей ключа под сертификатом RSA такого свойства не даёт, и в TLS 1.3 (RFC 8446) он убран. В SSH обмен выполняется алгоритмом curve25519-sha256 или ecdh-sha2-nistp256, а сессия защищается AES-GCM или chacha20-poly1305.

Отдельный слой - управление ключами. В крупных системах применяют схему конверта: данные шифрует короткоживущий ключ шифрования данных (DEK), сам DEK шифрует ключ шифрования ключей (KEK) в KMS или HSM. Это позволяет менять KEK, не перешифровывая терабайты.

Производительность: почему симметричное шифрование быстрее

Порядок величин на одном ядре современного серверного CPU: AES-256-GCM с AES-NI даёт 1-4 ГБ/с, ChaCha20-Poly1305 без аппаратной поддержки 0,5-1,5 ГБ/с. Для асимметрики счёт идёт на операции в секунду: RSA-2048 подписывает около 1000 раз в секунду, RSA-4096 примерно 150-200 раз в секунду, ECDSA на P-256 выдаёт 20 000-50 000 подписей в секунду, Ed25519 держится в диапазоне 15 000-70 000. Проверка подписи RSA-2048 выполняется 20 000-30 000 раз в секунду. Точные числа зависят от модели CPU, версии OpenSSL и сборки.

Причина разрыва в природе операций. Симметричный раунд - это XOR, подстановки по таблицам, циклические сдвиги и сложения 32- и 64-битных слов. Всё укладывается в регистры, а AES-NI выполняет раунд аппаратно. Асимметричная операция - модульное возведение в степень с 2048-битными числами или скалярное умножение точки кривой, где около 256 удвоений и сложений точек выполняются с арифметикой по модулю большого простого числа. Разница достигает 1000-10 000 раз.

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

Что выбрать: рекомендации для типовых задач

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

Защита канала связи: TLS и VPN

TLS 1.3 в 2026 году это базовый вариант для любого сетевого трафика. Ключи согласуются через ECDHE с X25519, трафик шифруется AES-256-GCM или ChaCha20-Poly1305. Наборы TLS_AES_128_GCM_SHA256 и TLS_AES_256_GCM_SHA384 равнозначны по практической стойкости, 128-битный вариант чуть быстрее. Из конфигурации убирают TLS 1.0 и 1.1, SSLv3, RC4, 3DES и режим с передачей ключа под сертификатом RSA. В Nginx это задаётся директивами ssl_protocols и ssl_ciphers, проверить результат можно так:

openssl s_client -connect your-host:443 -tls1_3 -brief

Для VPN выбор сводится к трём вариантам. WireGuard использует Curve25519 и ChaCha20-Poly1305, даёт минимальный оверхед и простую конфигурацию. IPsec/IKEv2 с AES-GCM-256 и SHA-384 привычен для межсайтовых соединений и требований регуляторов. OpenVPN на TLS остаётся там, где нужна работа через TCP 443. WireGuard выигрывает по производительности и простоте аудита конфигурации.

Шифрование файлов и дисков

Данные на носителе защищают симметрично. LUKS2 по умолчанию использует aes-xts-plain64 с 512-битным ключом (два 256-битных ключа для XTS) и Argon2id как функцию вывода ключа из пароля. BitLocker, ZFS native encryption и файловые системы со встроенным шифрованием работают по тому же принципу. Для отдельных файлов и бэкапов берут AES-256-GCM или ChaCha20-Poly1305: их применяют age, restic, borg с разными обвязками.

Асимметричное шифрование для томов не подходит из-за скорости. Единственное исключение - сценарий, где данные шифруют публичным ключом получателя и он единственный может их прочитать: так работают age и GPG при передаче файлов партнёру. Готовые схемы для LUKS2, ZFS, restic и borg с командами и планом ротации ключей разобраны в материале о шифровании данных при хранении и передаче.

Цифровая подпись и аутентификация

Подписи и аутентификация - территория асимметричных алгоритмов. Для новых систем выбирают Ed25519: короткие подписи размером 64 байта, высокая скорость, отсутствие требований к генератору случайных чисел при подписании. Для сертификатов X.509 берут ECDSA с P-256 или RSA-2048 и выше. Для совместимости с legacy-системами остаётся RSA-PSS с SHA-256.

JWT и токены доступа подписывают алгоритмами ES256, EdDSA или RS256. Артефакты сборки и контейнерные образы подписывают Sigstore или cosign с теми же Ed25519 и ECDSA. Подпись гарантирует целостность и авторство, конфиденциальности она не даёт: содержимое остаётся читаемым, поэтому его шифруют отдельно симметричным ключом.

Тренды 2026: постквантовая криптография и актуальность выбора

Алгоритм Шора теоретически ломает RSA и ECC на достаточно мощном квантовом компьютере, алгоритм Гровера вдвое сокращает эффективную длину симметричного ключа: AES-128 даёт 64 бита квантовой стойкости, AES-256 даёт 128 бит. Отсюда правило: симметрику оставляют на 256-битных ключах, асимметрику готовят к замене.

NIST стандартизировал первые постквантовые схемы в августе 2024 года: FIPS 203 (ML-KEM, бывший CRYSTALS-Kyber) для инкапсуляции ключей, FIPS 204 (ML-DSA, CRYSTALS-Dilithium) и FIPS 205 (SLH-DSA, SPHINCS+) для подписей. В марте 2025 года к ним добавили HQC как резервный KEM. Документ NIST IR 8547 задаёт ориентиры: RSA-2048 и ECC P-256 переходят в категорию устаревших после 2030 года и запрещаются после 2035 года.

Переход уже виден в коде. Chrome, Firefox и Cloudflare используют гибридный обмен X25519MLKEM768 в TLS. OpenSSH 9.9 и новее предлагает mlkem768x25519-sha256 как алгоритм по умолчанию, OpenSSL 3.5 получил поддержку ML-KEM, ML-DSA и SLH-DSA. Гибридная схема страхует от неизвестных уязвимостей новых алгоритмов и сохраняет стойкость к классическим атакам.

План на 2026 год: провести инвентаризацию, где применяются RSA и ECC (сертификаты, SSH-ключи, подписи артефактов, VPN), проверить, поддерживает ли библиотека гибридные схемы, и заложить crypto-agility, то есть возможность сменить алгоритм без переписывания протокола. Симметричную часть менять не нужно: AES-256 и ChaCha20 с 256-битным ключом остаются рабочим выбором.

Типичные ошибки при внедрении шифрования

• Режим ECB и статические IV. Одинаковые блоки дают одинаковый шифротекст, а повтор IV в CBC с включённым padding oracle открывает атаку на открытый текст.
• Повтор nonce в GCM и ChaCha20-Poly1305. Один и тот же nonce с одним ключом ломает и конфиденциальность, и целостность.
• Пароль напрямую как ключ. Ключ выводят функцией KDF: Argon2id, scrypt или PBKDF2 с уникальной солью и достаточным числом итераций. Как это работает и какие параметры брать, разобрано в статье о том, как пароль превращается в криптографический ключ.
• Слабый генератор случайных чисел. Ключи и nonce берут только из системного CSPRNG, а не из rand() и не из времени запуска.
• Хранение ключей рядом с данными: в том же каталоге, в git, в открытой переменной окружения или в конфиге с правами 644. Для ключей есть KMS, Vault и HSM.
• Отсутствие ротации. Ключи меняют по расписанию и при подозрении на компрометацию, DEK перешифровывают новым KEK без пересборки данных.
• Самодельная криптография. Берут готовые библиотеки: OpenSSL, libsodium, age, проверенные сборки TLS и SSH.
• Устаревшие алгоритмы: DES, 3DES, RC4, MD5, SHA-1 в подписях и 1024-битный RSA.
• Отключённая проверка сертификатов и самоподписанные сертификаты в продакшене, что сводит аутентификацию канала к нулю.
• Игнорирование атак по сторонним каналам: сравнение тегов не за постоянное время, утечки через кеш и время выполнения.

Практические примеры в DevOps и системном администрировании

SSH. Аутентификация идёт асимметричными ключами, сессия шифруется симметрично. Для новых ключей берут Ed25519, для совместимости с legacy-оборудованием RSA-4096. Приватный ключ защищают парольной фразой и не копируют на серверы.

ssh-keygen -t ed25519 -a 100 -C devops@example

TLS для веб-серверов. Let's Encrypt выпускает сертификаты ECDSA с P-256, Nginx настраивают на TLS 1.3 и 1.2 с ECDHE X25519. Автоматическое продление через certbot или acme.sh убирает человеческий фактор.

Kubernetes. Секреты в etcd шифруют на стороне API-сервера: в EncryptionConfiguration выбирают провайдер aesgcm (AES-256-GCM) или secretbox (XSalsa20-Poly1305), а в управляемых кластерах обычно доступен провайдер kms с внешним ключом. Без шифрования etcd секреты лежат в base64, что защитой не считается. При развёртывании управляемого кластера проверьте, включено ли шифрование etcd по умолчанию; облачные платформы вроде Timeweb Cloud дают Kubernetes и хранилище в одной панели, что упрощает контроль над настройками безопасности.

VPN на WireGuard. Обмен ключами идёт через Curve25519, трафик шифруется ChaCha20-Poly1305, конфигурация читается целиком за минуту.

[Interface]
PrivateKey = приватный ключ клиента
Address = 10.10.0.2/32

[Peer]
PublicKey = открытый ключ сервера
Endpoint = vpn-server:51820
AllowedIPs = 0.0.0.0/0

Бэкапы. restic шифрует репозиторий схемой AES-256-CTR с аутентификацией Poly1305-AES, ключ выводится из пароля через scrypt. age использует X25519 и ChaCha20-Poly1305 и удобен для шифрования файлов на публичный ключ получателя. Сравнение инструментов командной строки с командами и таблицей выбора приведено в обзоре программ и утилит для шифрования данных.

Управление секретами. Пароли баз данных, токены API и приватные ключи держат в Vault, в KMS облачного провайдера или в HSM, а в конфигурации оставляют ссылку на секрет. Разделение клиентского и серверного шифрования для файловых хранилищ и NAS, ротация ключей и вынос их в HSM разобраны в статье о клиентской, серверной и гибридной моделях шифрования. Для домашней лаборатории на TrueNAS или сервера с ZFS это выбор между ZFS native encryption и шифрованием на стороне клиента.

Начните с трёх шагов. Первый: выпишите, где в инфраструктуре применяются RSA и ECC, чтобы понимать объём будущей миграции на постквантовые схемы. Второй: включите TLS 1.3 с ECDHE X25519 и убедитесь, что старые протоколы отключены. Третий: проверьте, что секреты, бэкапы и диски защищены AES-256-GCM или ChaCha20-Poly1305, а ключи лежат в KMS или HSM, а не рядом с данными. Этого набора хватает, чтобы закрыть основные риски 2026 года и не переделывать архитектуру при переходе на ML-KEM и ML-DSA.