Ключ шифрования данных: выбор длины и алгоритма с оговорками
Допустим, вы настраиваете шифрование для своего проекта — личного облака, корпоративного хранилища, или просто выбираете параметры TLS для внутреннего сервиса. Открываете документацию, а там гордо написано: «поддерживает RSA-2048».
И возникает тот самый вопрос, который в 2026 году задают себе все — от DevOps-инженеров до архитекторов безопасности: нормально это или пора уже что-то менять?
Спойлер: RSA-2048 пока работает, но NIST в проекте SP 800-131A Revision 3 от октября 2024 года уже обозначил дату вывода — конец 2030 года. То есть у вас в запасе не так много времени, как кажется, особенно если данные рассчитаны на длительное хранение. Давайте разберёмся, какие ключи сегодня брать, какие алгоритмы внедрять прямо сейчас, а с чем можно подождать.
RSA-2048 и тихий дедлайн: что значит «112 бит стойкости»
Сам по себе RSA-2048 не сломан и не запрещён — он попросту доживает свой срок. NIST относит его к уровню стойкости 112 бит, что в 2026 году считается минимально допустимым для новых систем, но не рекомендуемым для долгосрочной защиты.
Что это за «уровень стойкости» в переводе на человеческий? Грубо говоря, это оценка того, сколько вычислительных операций потребуется злоумышленнику, чтобы вскрыть ключ. 112 бит — это порядка 2^112 операций. Звучит как астрономическая цифра, но прогресс в железе и алгоритмах (например, постоянные улучшения в решете числового поля) постепенно сокращают дистанцию. Поэтому NIST и говорит: для архивных данных RSA-2048 ещё сгодится и после 2030 года, а вот для нового трафика — лучше сразу закладывать запас.
На практике это означает три конкретных шага:
1. Если вы сейчас запускаете новый сервис или продлеваете сертификат — берите RSA-3072 или RSA-4096. Разница в производительности заметна только на самых нагруженных узлах, запас прочности — десятилетия.
2. Если у вас уже стоит RSA-2048 в legacy-системах — не паникуйте. До конца 2030 года это допустимо, но закладывайте план миграции.
3. Следите за открытой экспонентой. Используйте e = 65537 — стандартная рекомендация для борьбы с атаками на подделку подписи. Маленькие значения вроде e = 3 — путь к известным уязвимостям.
RSA-2048 сегодня — как старый, но всё ещё работающий холодильник. Выбросить жалко, новый покупать страшно. Но если переезжать всё равно придётся, лучше делать это планово, а не в авральном режиме.
Симметричное шифрование: когда 128 бит мало, а когда — достаточно
С симметричными ключами шифрования данных ситуация одновременно проще и запутаннее. AES-128 — золотой стандарт индустрии, и для большинства задач его более чем хватает. Но если вы работаете с информацией, которая должна оставаться зашифрованной 10, 20, 30 лет — медицинские записи, государственные архивы, долгосрочные коммерческие тайны — разумно сразу брать AES-256.
Почему? Дело не в том, что AES-128 кто-то «сломает», а в том, что требования к оборудованию и софту меняются. Немецкий BSI в руководстве TR-02102-1 прямо рекомендует AES-256 для систем с длительным жизненным циклом. NIST в проекте SP 800-57 Part 1 Revision 6 (декабрь 2025 года) идёт ещё дальше — туда уже включили легковесное шифрование Ascon (SP 800-232) и постквантовые алгоритмы.
Ключевой нюанс, который многие упускают: криптопериод симметричного ключа шифрования данных (DEK) по рекомендациям NIST — не более 2 лет. После этого ключ нужно ротировать. И здесь кроется частая ошибка: люди ротируют ключ, но забывают перешифровать старые данные новым. В итоге архив остаётся защищён ключом, который формально уже «умер», а фактически всё ещё используется для расшифровки.
Давайте посмотрим на сравнение в чистом виде:
| Параметр | AES-128 | AES-256 |
|---|---|---|
| Уровень стойкости | 128 бит | 256 бит |
| Когда хватает | Стандартные коммерческие данные, сессионный трафик, дисковые тома | Долгосрочные архивы, государственные системы, данные с жёстким регулированием |
| Производительность | Базовая линия | Примерно на 20–40% медленнее (зависит от реализации) |
| Аппаратная поддержка | AES-NI повсеместно | AES-NI повсеместно |
Ожидание: «AES-128 устарел, надо срочно переходить на 256».
Реальность: для большинства обычных задач AES-128 хватит ещё надолго. Переходить на 256 нужно только там, где есть жёсткие регуляторные требования или данные рассчитаны на десятилетия.
Постквантовая эра: что уже стандартизировано и как это внедрять
В августе 2024 года NIST официально утвердил три первых стандарта постквантовой криптографии:
- FIPS 203 — ML-KEM (инкапсуляция ключей, бывший Kyber);
- FIPS 204 — ML-DSA (цифровые подписи, бывший Dilithium);
- FIPS 205 — SLH-DSA (подписи на основе хеш-функций, бывший SPHINCS+).
Звучит как чистая теория, но директива CNSA 2.0 от АНБ переводит это в жёсткие сроки:
- с 1 января 2027 года все новые закупки оборудования для систем нацбезопасности США должны поддерживать квантово-устойчивые алгоритмы;
- к 31 декабря 2030 года всё устаревшее оборудование должно быть выведено из эксплуатации;
- полный переход систем нацбезопасности США на постквантовые алгоритмы — к 2035 году.
Это не абстрактные рекомендации — это конкретные дедлайны для огромного рынка. И если вы работаете с американскими партнёрами, госсектором или критической инфраструктурой, эти сроки начинают диктовать вашу архитектуру.
Что делать «обычному» пользователю — тому, кто не обслуживает АНБ?
1. Следить за поддержкой в своих инструментах. OpenSSL свежих версий, BoringSSL, экспериментальные сборки WireGuard — постквантовая поддержка появляется и работает.
2. Использовать гибридные схемы. Например, X25519+ML-KEM-768 в TLS — классический ключ плюс постквантовый. Если квантовый компьютер так и не построят, вы ничего не потеряли; если построят — защищены.
3. Не паниковать. Полностью классические схемы вроде RSA-3072 и Curve25519 остаются безопасными против всех известных классических атак. Постквантовая защита нужна для долгосрочных секретов, а не для каждого TLS-соединения.
Постквантовая криптография — это не про «квантовый компьютер взломает всё завтра». Это про «секрет, который вы закладываете сегодня, должен остаться секретным в 2040 году». Атака «harvest now, decrypt later» уже реальность: трафик записывают сейчас, расшифровать планируют потом.
Криптопериоды и ротация: где чаще всего спотыкаются
Отдельная категория боли — управление жизненным циклом ключей шифрования данных. Технически тут всё просто: есть рекомендация NIST (2 года для DEK), есть конкретные даты вывода из эксплуатации (2030 для 112-битных ключей), есть инструменты вроде HashiCorp Vault, AWS KMS, GCP KMS. Сложность не в самих правилах, а в том, как они стыкуются с реальной инфраструктурой.
Типичная ошибка номер один: ротация без перешифрования. Сменили ключ, новые записи пишутся уже под ним, а весь архив за 5 лет лежит под старым. Если злоумышленник получит доступ к старому ключу (через скомпрометированный бэкап, например), он прочитает всё.
Типичная ошибка номер два: забытый ключ дешифрования. Срок действия истёк, ключ помечен как retired, но приложение по привычке пытается им расшифровать. В логах — ошибки, у пользователей — невозможность открыть собственные файлы.
Типичная ошибка номер три: ручная ротация в критических системах. Без автоматизации это вопрос времени, когда кто-то забудет. Решение — KMS с автоматической ротацией и политиками lifecycle.
Что настроить в первую очередь:
- Назначьте владельца каждого ключа. Не «команда безопасности», а конкретный человек или сервис-аккаунт с ответственностью.
- Задокументируйте криптопериод. Когда создан, когда истекает, что делать с данными после.
- Настройте мониторинг. Предупреждение за 90 дней до истечения, а не в день истечения.
- Проверьте бэкапы. Если ключ для расшифровки бэкапа утерян — сам бэкап бесполезен.
- Разделите ключи по доменам. Ключ для production, ключ для staging и ключ для аналитики — это три разных ключа.
Российская специфика: «Кузнечик», «Магма» и когда они нужны
Если ваш проект работает с российскими госструктурами, критической инфраструктурой или подпадает под требования регуляторов — выбор алгоритма диктуется не столько NIST, сколько ГОСТ Р 34.12-2015. Этот стандарт определяет два базовых блочных шифра:
- «Кузнечик» — 128-битный блок, 256-битный ключ. Современная рекомендация, актуальная для новых внедрений.
- «Магма» — 64-битный блок, 256-битный ключ. Старая советская схема, адаптированная под новый стандарт.
Важный момент: длина ключа в обоих случаях 256 бит, но размер блока разный. «Магма» с 64-битным блоком в современных реалиях выглядит архаично — режимы вроде CBC на таких блоках уязвимы к атакам типа Sweet32. Если у вас есть выбор — берите «Кузнечик». «Магма» остаётся в legacy-системах и в тех случаях, когда требуется совместимость со старым оборудованием.
По постквантовым алгоритмам в России финальные спецификации пока не утверждены — ожидаются ориентировочно в 2026–2027 годах. Но направление понятно: отечественные реализации ML-KEM и ML-DSA уже обсуждаются в ТК 26, и в перспективе пары лет мы увидим первые стандарты. Если проектируете систему с длительным сроком жизни — закладывайте криптоагностичность, чтобы потом не переписывать всё с нуля.
Итог: что брать в 2026 году
Если собрать всё вышесказанное в одну таблицу решений, получится примерно так:
| Задача | Рекомендация | Почему |
|---|---|---|
| Новый TLS-сертификат | RSA-3072 или ECDSA P-256 | Достаточно для следующих 10+ лет, совместимо со всем парком клиентов |
| Долгосрочное хранение данных | AES-256 + план миграции на постквантовые | Защита от «harvest now, decrypt later» |
| Соответствие требованиям РФ | «Кузнечик» (ГОСТ Р 34.12-2015) | Обязательно для ряда отраслей и регуляторов |
| Госсектор США / критическая инфраструктура | ML-KEM + ML-DSA | Дедлайны CNSA 2.0 уже на горизонте |
| Личные проекты и эксперименты | AES-256 или ChaCha20-Poly1305 | Просто, быстро, без сюрпризов в поддержке |
Главный вывод, который я бы вынес из всего этого: не существует «идеального» ключа шифрования данных — есть ключ, который соответствует вашему сценарию, сроку жизни данных и регуляторному контексту. RSA-2048 сегодня — не катастрофа, но и не то, что стоит закладывать в новые системы. AES-128 — рабочая лошадка, но для архивов на десятилетия разумно сразу брать 256. Постквантовые алгоритмы — это уже не теория, а конкретные стандарты с дедлайнами внедрения. И чем раньше вы начнёте планировать миграцию, тем меньше боли будет в 2030 году.
