Алгоритмы шифрования данных: от AES до постквантовых схем (обзор 2026)

Для большинства рабочих задач в 2026 году хватает четырех алгоритмов: AES-256-GCM для симметричного шифрования, X25519 или P-256 для обмена ключами и подписей, Argon2id для паролей и гибрид X25519MLKEM768 там, где данные должны оставаться закрытыми и после появления криптографически значимого квантового компьютера. Остальное - либо надстройка над этим набором, либо наследие, которое пора выводить из эксплуатации.

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

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

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

Симметричное шифрование: скорость и эффективность

AES-256-GCM на одном ядре с аппаратным ускорением AES-NI выдает 3-6 ГБ/с, ChaCha20-Poly1305 на том же ядре - примерно 1-2 ГБ/с. На практике пропускную способность ограничивает диск или сеть, а не сам шифр. Поэтому симметричные алгоритмы берут на себя основную работу: содержимое дисков, поля в базе, тело TLS-сессии, резервные копии.

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

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

Асимметричные операции медленнее симметричных на два-три порядка. Проверка подписи RSA-2048 на современном CPU дает 20-30 тысяч операций в секунду, а сама подпись - около 1000-2000 операций в секунду, потому что требует модульного возведения в степень с приватным ключом. Ed25519 подписывает и проверяет десятки тысяч сообщений в секунду. Шифровать асимметрикой гигабайты данных бессмысленно, для этого есть гибридные схемы.

Гибридный подход применяют в TLS 1.3: асимметричный обмен ключами (ECDHE) создает общий секрет на время сессии, а трафик шифруется симметричным AES-256-GCM или ChaCha20-Poly1305. Асимметричные алгоритмы закрывают три задачи: согласование ключа, цифровая подпись и аутентификация. Выбор между ними зависит от объема данных, требований к задержке и необходимости передать ключ по открытому каналу.

AES: стандарт симметричного шифрования и длина ключа

AES работает с блоками по 128 бит и поддерживает ключи 128, 192 и 256 бит. Алгоритм стандартизирован с 2001 года, проверен двумя десятилетиями криптоанализа и ускорен в железе: инструкции AES-NI есть в процессорах Intel и AMD начиная с 2010 года, аналогичные расширения присутствуют в ARMv8. Практический вывод: AES-128 держит 128-битную стойкость и не имеет известных практических атак; AES-256 берут там, где нужен запас на десятилетия или этого требует регулятор.

Цена перехода на 256-битный ключ в 2026 году почти незаметна. Без аппаратного ускорения AES-256 примерно на 40% медленнее AES-128, с включенным AES-NI разрыв сокращается до 10-20%, и на типовой нагрузке разница тонет в накладных расходах ввода-вывода. Значение имеют не длина ключа, а режим работы и управление ключами.

Режимы работы AES: ECB, CBC, GCM и другие

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

• ECB шифрует каждый блок независимо. Одинаковые блоки открытого текста дают одинаковые блоки шифротекста, поэтому структура данных (например, повторяющиеся значения в колонке) видна без ключа. Не использовать в новом коде.
• CBC связывает блоки через вектор инициализации. Требует уникального случайного IV на каждое сообщение, иначе утекает информация о совпадении префиксов. Не дает аутентификации и уязвим к атакам типа padding oracle, если приложение по-разному отвечает на ошибки расшифрования.
• CTR превращает блочный шифр в потоковый. Быстрый, распараллеливается, но тоже не аутентифицирует данные: подмена байта в шифротексте приводит к предсказуемому изменению открытого текста.
• GCM объединяет CTR с аутентификацией по GHASH. Один ключ и один nonce нельзя использовать дважды: повтор nonce в GCM ломает и конфиденциальность, и целостность. При корректной работе с nonce это оптимальный выбор для сетевых протоколов и полей в БД.
• XTS создан для шифрования блоковых устройств: он устойчив к перестановке блоков на диске и не требует хранения nonce. Применяется в LUKS2 и BitLocker.

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

Практическое применение AES в OpenSSL и libsodium

В OpenSSL AES доступен через EVP API: EVP_EncryptInit_ex с EVP_aes_256_gcm, отдельные вызовы для передачи AAD, получения тега и финализации. Утилита командной строки для AEAD-режимов не подходит: openssl enc не поддерживает GCM и CCM, попытка выполнить шифрование файла с флагом aes-256-gcm завершится ошибкой. Для файлов на диске используют aes-256-cbc с обязательным -pbkdf2 и высоким числом итераций, либо внешние инструменты вроде age и GPG, либо собственный код на EVP.

В libsodium логика другая: библиотека сама выбирает быстрый примитив под железо. Функция crypto_aead_aes256gcm_encrypt работает только при наличии AES-NI и сообщает об этом через crypto_aead_aes256gcm_is_available, а по умолчанию для симметричного шифрования применяется ChaCha20-Poly1305 (crypto_aead_chacha20poly1305_ietf_encrypt) либо crypto_secretbox. Такой выбор снимает проблему timing-атак на табличные реализации AES и одинаково хорошо работает на мобильных ARM-платформах.

Устаревшие алгоритмы DES, 3DES, MD5, SHA-1: почему их нельзя использовать

DES с 56-битным ключом перестал быть стойким в 1998 году: специализированная машина EFF Deep Crack стоимостью около 250 тысяч долларов подобрала ключ за 56 часов, а совместный проект с distributed.net уложился в 22 часа. Сегодня перебор 56 бит занимает минуты на арендованных GPU.

3DES формально дает 112 или 168 бит, но из-за meet-in-the-middle эффективная стойкость ниже, а атака Sweet32 (CVE-2016-2183) позволяет восстановить открытый текст в долгоживущих сессиях с большим объемом трафика. NIST прекратил использовать 3DES для новых систем: в соответствии со SP 800-131A Rev. 2 режим признан недопустимым после 2023 года. Поддержка в OpenSSL сохранена для совместимости и отключается настройками провайдера.

MD5 и SHA-1 непригодны для подписей и контроля целостности из-за коллизий. Практическая эксплуатация MD5 состоялась в 2012 году: вредонос Flame подделал сертификат подписи кода Microsoft, сконструировав коллизию. Для SHA-1 атака SHAttered в 2017 году показала стоимость коллизии порядка 110 тысяч GPU-лет, что по облачным расценкам сводится к десяткам тысяч долларов. Обе функции также не годятся для хеширования паролей: их скорость как раз и делает перебор дешевым.

План миграции для инфраструктуры выглядит так: собрать список мест, где встречаются legacy-шифры (конфиги nginx, sshd_config, параметры Java, строки подключения к БД), отключить их на стороне сервера, затем выкатить клиентам обновленные списки. Инвентаризацию ускоряет автоматический разбор конфигураций: например, прогон файлов через LLM-ассистента с доступом к документации по конкретной версии ПО. Такой доступ к более чем 200 моделям через единый API без VPN дает AiTunnel, что удобно, когда нужно быстро проверить десятки однотипных конфигов на упоминания DES, 3DES и SHA-1.

Асимметричные алгоритмы RSA и ECC: выбор длины ключа

Стойкость асимметричных схем сравнивают через эквивалент симметричного ключа. RSA-2048 дает около 112 бит стойкости, ECC-256 - 128 бит, и это ключевой аргумент в пользу эллиптических кривых: меньший ключ при большей стойкости.

RSA: длина ключа и производительность

RSA-2048 остается минимально допустимым уровнем, но NIST в проекте IR 8547 предлагает снять его с эксплуатации к 2030 году и запретить после 2035 года вместе с P-256. Для новых систем практичный выбор - RSA-3072 или переход на эллиптику. Генерация ключа RSA-4096 занимает секунды на быстром CPU и десятки секунд на слабом виртуальном инстансе, что важно при массовом создании сертификатов. Проверка подписи дешева, подпись дорога.

В OpenSSL ключ RSA-3072 создают командой openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072. Минимальный размер ключа в TLS регулируется директивой ssl_ciphers или параметрами политики безопасности; на старых клиентах значение 1024 бита все еще встречается, и его нужно отсекать.

ECC: эффективность при меньшей длине ключа

P-256 (prime256v1, secp256r1) дает 128-битную стойкость при ключе 256 бит, подпись занимает около 64 байт в формате raw. Curve25519 в варианте X25519 применяется для согласования ключей, Ed25519 - для подписей: 32-байтовый публичный ключ и 64-байтовая подпись, детерминированная схема без генератора случайных чисел на этапе подписи. Ed25519 реализован в libsodium функцией crypto_sign_ed25519 и в OpenSSL как ED25519.

Генерация ключа ECC почти мгновенная, что позволяет выпускать краткоживущие сертификаты и не держать долгоживущие приватные ключи на серверах. В OpenSSL эллиптический ключ создают так: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256. Устаревший вариант openssl ecparam -genkey -name prime256v1 работает, но в новых скриптах лучше использовать genpkey: он единообразен для всех типов ключей.

Постквантовые алгоритмы шифрования: Kyber и Dilithium

Алгоритм Шора сводит факторизацию и дискретное логарифмирование к полиномиальной задаче, поэтому RSA и ECC после появления достаточно мощного квантового компьютера перестанут защищать. Оценки для RSA-2048 в 2026 году сходятся на том, что атакующему понадобятся миллионы физических кубитов с коррекцией ошибок, и практический срок сдвигается в 2030-е годы. Риск в другом: данные с длительным сроком хранения перехватывают сегодня, чтобы расшифровать потом.

13 августа 2024 года NIST опубликовал первые постквантовые стандарты: FIPS 203 (ML-KEM, на базе CRYSTALS-Kyber), FIPS 204 (ML-DSA, на базе CRYSTALS-Dilithium) и FIPS 205 (SLH-DSA, хеш-подписи на базе SPHINCS+). Первые два основаны на сложности задач на решетках и дают компактные ключи при приемлемой скорости.

Kyber: обмен ключами, устойчивый к квантовым атакам

ML-KEM - механизм инкапсуляции ключа (KEM): сторона с публичным ключом формирует общий секрет и шифротекст, владелец приватного ключа извлекает тот же секрет. Уровни безопасности: ML-KEM-512 сопоставим с AES-128, ML-KEM-768 с AES-192, ML-KEM-1024 с AES-256.

Размеры ключей в разы больше, чем у X25519 (32 байта), поэтому в TLS применяют гибрид: общий секрет получают и классическим ECDH, и KEM, а ключ сессии выводят из обоих. Взлом одного из алгоритмов не компрометирует сессию. Группа X25519MLKEM768 включена по умолчанию в Chrome с 2024 года и в OpenSSL 3.5, поддержка есть в Go и BoringSSL. В OpenSSL 3.5 ключ ML-KEM создают командой openssl genpkey -algorithm ML-KEM-768.

Dilithium: цифровые подписи на решётках

ML-DSA закрывает вторую половину постквантовой задачи: подписи для сертификатов, обновлений прошивок, подписи артефактов сборки. Уровни ML-DSA-44, ML-DSA-65 и ML-DSA-87 соответствуют 128, 192 и 256 битам стойкости.

Подпись Dilithium занимает килобайты против 64 байт у Ed25519 и примерно 256 байт у RSA-3072. Это увеличивает размер сертификатов и рукопожатий TLS, поэтому в протоколах подписи переходят на постквантовые схемы позже, чем обмен ключами. Есть и хеш-вариант: SLH-DSA дает минимальные требования к доверию (стойкость опирается только на хеш-функцию), но подписи вырастают до 7-50 КБ, что подходит для подписи релизов, а не для интерактивных сессий.

Хранение паролей: алгоритмы хеширования и параметры

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

bcrypt, scrypt, Argon2: сравнение и выбор

• bcrypt устойчив к GPU-перебору благодаря 4 КБ рабочей памяти на поток, проверен пятнадцатью годами эксплуатации, но обрезает пароль на 72 байтах, а часть реализаций обращается с нулевым байтом внутри пароля некорректно.
• scrypt требователен к памяти, что затрудняет перебор на ASIC и GPU. Параметры по умолчанию в OpenSSL - N=2^14, r=8, p=1, для новых систем поднимают N до 2^15-2^17 (32-128 МиБ).
• Argon2id победитель Password Hashing Competition 2015 года, сочетает защиту от GPU-перебора (memory-hard) с устойчивостью к side-channel атакам в первой половине вычисления. Рекомендуемый выбор для новых проектов.
• PBKDF2 остается в FIPS-контурах и старых системах. Итерации приходится ставить на уровне 600 000 для SHA-256, чтобы приблизиться по стоимости к memory-hard схемам.

Рабочие параметры на 2026 год: Argon2id с memory=64 МиБ, iterations=3, parallelism=4 для серверов с запасом CPU; минимально допустимый профиль OWASP - memory=19 МиБ, iterations=2, parallelism=1. bcrypt с cost=12 дает задержку около 250 мс на среднем ядре. scrypt с N=2^15, r=8, p=1. Целевой ориентир один: одна проверка пароля должна занимать 100-500 мс, тогда как массовый перебор на GPU становится нерентабельным.

Практическая настройка хеширования паролей

В libsodium функцию crypto_pwhash_str вызывают с пресетами OPSLIMIT_INTERACTIVE и MEMLIMIT_INTERACTIVE, а для чувствительных сервисов переходят на SENSITIVE-варианты. В Python удобна библиотека passlib: CryptContext(schemes=['argon2', 'bcrypt'], default='argon2') позволяет хранить старые bcrypt-хеши и автоматически переводить их на Argon2id при следующем успешном входе пользователя. Соль генерируется внутри функции и записывается в строку хеша, отдельно ее хранить не нужно. Дополнительный секрет (pepper) добавляют через HMAC с ключом из KMS: он не попадает в базу вместе с хешами. Подробное сравнение алгоритмов и схемы миграции без сброса паролей собраны в статье о выборе алгоритма хеширования паролей, а защита самого хранилища от перебора описана в руководстве по защите хранилища паролей от брутфорса.

Выбор алгоритма под задачу: шифрование БД, сетевой трафик, хранение паролей

Универсального алгоритма нет, но есть отработанные связки под каждый тип данных. Ниже - то, что имеет смысл ставить в 2026 году.

Шифрование данных в базе: AES-256-GCM и прозрачное шифрование

Поля, содержащие персональные данные, номера карт, токены, шифруют на уровне приложения алгоритмом AES-256-GCM с ключом из KMS. Nonce генерируют случайно для каждого значения, тег аутентификации хранят рядом с шифротекстом. Такой подход не зависит от версии СУБД и работает при переносе дампа на другой сервер.

В PostgreSQL расширение pgcrypto дает функции pgp_sym_encrypt и pgp_sym_decrypt, но по умолчанию используется AES-128 в режиме OpenPGP CFB без аутентификации; в вызове нужно явно указать cipher-algo=aes256 и помнить, что AEAD здесь нет. В MySQL функция AES_ENCRYPT по умолчанию работает в режиме aes-128-ecb, что недопустимо для чувствительных данных; переменная block_encryption_mode позволяет переключиться на aes-256-cbc, но GCM в этой функции недоступен, поэтому шифрование переносят в приложение. Прозрачное шифрование табличных пространств (TDE) закрывает только файлы на диске и не защищает от SQL-инъекции с правами на чтение.

Диск и резервные копии шифруют отдельно: LUKS2 с aes-xts-plain64 и 512-битным ключом, ZFS native encryption, для бэкапов - restic или borg с ChaCha20-Poly1305. Компромиссы между клиентским, серверным и гибридным шифрованием разобраны в статье о клиентской, серверной и гибридной моделях шифрования. Если база и хранилище размещены в облаке, стоит проверить, шифрует ли провайдер диски и снапшоты на своей стороне и есть ли доступ к ключам через API; подходящие варианты инфраструктуры с базами данных и объектным хранилищем перечислены у Timeweb Cloud.

Защита сетевого трафика: TLS 1.3 и постквантовые гибриды

TLS 1.3 оставляет три набора шифров: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 и TLS_CHACHA20_POLY1305_SHA256. Статический обмен ключами по RSA убран, остается (EC)DHE, что дает прямую секретность. Практическая настройка: список групп X25519 и P-256, отключение TLS 1.0/1.1 и всех CBC-наборов, включение OCSP stapling.

Для защиты от будущего квантового противника добавляют гибридную группу X25519MLKEM768. В OpenSSL 3.5 она входит в набор по умолчанию, в nginx задается директивой ssl_ecdh_curve X25519MLKEM768 или через ssl_conf_command Groups X25519MLKEM768. Работоспособность зависит от сборки: nginx должен быть слинкован с OpenSSL 3.5, а не с системной версией 3.0. Проверить фактически согласованную группу можно командой openssl s_client -connect host:443 -groups X25519MLKEM768 и разбором строки Server Temp Key в выводе. Некоторые балансировщики и WAF не пропускают ClientHello увеличенного размера: гибридный обмен добавляет к рукопожатию больше килобайта и на плохо настроенных промежуточных узлах приводит к обрыву соединения.

Поддержка алгоритмов в OpenSSL и libsodium: версии и команды

OpenSSL 3.5 (апрель 2025) включает ML-KEM, ML-DSA и SLH-DSA на уровне ядра, без внешних провайдеров. Проверить доступный набор можно командами openssl list -kem-algorithms и openssl list -signature-algorithms. На ветках 3.0-3.4 постквантовые схемы подключают отдельным провайдером oqs-provider из проекта liboqs: он регистрирует алгоритмы Kyber768, Dilithium3 и их гибридные комбинации, но требует совпадения версий и аккуратной работы с конфигом openssl.cnf. Для проверки AES-режимов служит openssl list -cipher-algorithms, а для фактического согласования в тесте - openssl s_client с флагами -tls1_3 и -ciphersuites.

libsodium 1.0.19 остается библиотекой для прикладных задач: crypto_aead_chacha20poly1305_ietf_encrypt, crypto_aead_aes256gcm_encrypt при наличии AES-NI, crypto_sign_ed25519, crypto_scalarmult (X25519), crypto_pwhash (Argon2id), crypto_generichash (BLAKE2b). Постквантовых схем в libsodium нет: авторы последовательно отказываются добавлять экспериментальные примитивы до стабилизации стандартов. Если требуется постквантовая подпись в приложении на C, подключают liboqs напрямую либо пользуются OpenSSL 3.5. Для контрольных сумм и индексов в libsodium применяют crypto_generichash вместо SHA-1 и MD5, а SHA-256 и SHA-3 остаются в OpenSSL для совместимости с внешними системами.

Итоговые рекомендации и таблица выбора алгоритмов

Сводная таблица закрывает типовые задачи администратора и разработчика.

Порядок внедрения для новой системы: включить TLS 1.3 с AES-256-GCM и X25519MLKEM768, шифровать чувствительные поля на уровне приложения, хранить пароли в Argon2id, подписывать артефакты Ed25519 с планом перехода на ML-DSA-65 при обновлении OpenSSL. Для существующей инфраструктуры первым шагом вычистить DES, 3DES, RC4, MD5 и SHA-1 из конфигов, вторым - поднять параметры хеширования паролей, третьим - добавить гибридный обмен ключами в TLS.

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