Руководство по AES-256: защита файлов военного уровня

AES-256 — симметричный блочный шифр, одобренный АНБ США для данных категории TOP SECRET согласно CNSSP-15. Он шифрует 128-битные блоки 256-битным ключом в 14 раундов операций подстановки, перестановки и смешивания. Для взлома одного ключа AES-256 перебором потребуется в среднем около 2^255 операций — число настолько велико, что все компьютеры Земли не справились бы за время жизни Вселенной. Именно поэтому каждый серьёзный сервис передачи файлов, от SwissTransfer до Tresorit, использует AES-256 как основной шифр. Вот как он работает на самом деле.

Откуда берётся число «256»

AES выпускается в трёх размерах ключа: 128, 192 и 256 бит. Число относится только к длине ключа, а не к размеру блока (он всегда 128 бит). Длина ключа определяет количество раундов шифра: 10 для AES-128, 12 для AES-192, 14 для AES-256.

Больше раундов означает большее рассеивание — каждый выходной бит зависит от большего числа входных битов — и большую устойчивость к криптоаналитическим атакам, например к атаке двойной клики (biclique attack), опубликованной в 2011 году, которая теоретически снижает эффективную стойкость AES-256 с 256 до 254,4 бит. Это всё ещё далеко за пределами любой практической атаки.

Федеральный стандарт обработки информации FIPS 197 определяет AES, а NIST SP 800-38A — 800-38G задают режимы работы.

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

AES — блочный шифр, то есть он умеет шифровать лишь один 128-битный блок. Чтобы зашифровать файл произвольного размера, нужен режим работы. Выбор имеет принципиальное значение:

ECB (Electronic Codebook): одинаковые блоки открытого текста дают одинаковый шифротекст. Никогда не используйте. Знаменитое «ECB-изображение пингвина» наглядно демонстрирует: контуры Tux просматриваются сквозь ECB-зашифрованные пиксели.
CBC (Cipher Block Chaining): применяет XOR к каждому блоку с предыдущим шифротекстом. Безопасен в паре с HMAC для аутентификации, но CBC без него уязвим к атакам padding oracle (POODLE поразил SSL в 2014 году).
GCM (Galois/Counter Mode): шифрует счётчиком и за один проход создаёт 128-битный тег аутентификации. Вмешательство в шифротекст громко ломает расшифровку. Это то, что используют современные сервисы.

AES-256-GCM — стандарт по умолчанию в TLS 1.3, Signal, WireGuard и каждом достоверном сервисе передачи файлов. Если сервис упоминает «AES-256» без указания режима — предполагайте GCM и проверьте.

IV (nonce), который нельзя использовать повторно

GCM требует уникального 96-битного вектора инициализации для каждого шифрования с данным ключом. Повторное использование IV с тем же ключом даже однажды позволяет злоумышленнику применить XOR к двум шифротекстам и восстановить открытый текст — катастрофический сбой, ставший основой известной атаки на WEP Wi-Fi.

Лучшая практика: генерировать IV с помощью криптографически стойкого генератора случайных чисел (crypto.getRandomValues() в браузерах, /dev/urandom в Linux) и добавлять его к шифротексту в начало. 96-битный случайный IV имеет вероятность коллизии около 2^-48 после шифрования 2^32 файлов — допустимо для сервиса передачи. При повторном использовании ключа для миллиардов файлов вместо него применяется детерминированный счётчик.

Получение ключа: от пароля к ключу шифрования

Пользователи хотят пароли вроде mydog2024. AES требует 256 бит равномерной случайности. Мостом между ними служит функция получения ключа (KDF). В широком использовании три варианта:

PBKDF2 с HMAC-SHA-256 и 600 000 итераций (рекомендация OWASP 2023). Широко поддерживается, доступна в Web Crypto API.
scrypt добавляет требования к памяти, увеличивая стоимость атак на GPU. Используется в Bitcoin и LastPass.
Argon2id — текущая лучшая практика, победитель Password Hashing Competition 2015. Параметры: memory=64 МБ, iterations=3, parallelism=4.

12-символьный случайный пароль через Argon2id займёт у современного GPU порядка миллиарда лет. Слабый пароль вроде password123 падёт за миллисекунды — независимо от KDF.

AES в браузере: Web Crypto API

Браузеры предоставляют AES-256-GCM нативно через window.crypto.subtle. Типичный поток:

const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 },
  true,
  ["encrypt", "decrypt"]
);
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  fileBytes
);

Современные процессоры с инструкциями AES-NI ускоряют это до примерно 3–5 ГБ/с на ядро. Файл в 1 ГБ шифруется менее чем за секунду на среднем ноутбуке. На мобильных устройствах Apple A-series и Qualcomm Snapdragon включают ARMv8 Crypto Extensions с аналогичной производительностью.

От чего защищает AES-256 (и от чего нет)

AES-256 решает одну конкретную задачу: конфиденциальность данных в покое или при передаче при условии, что ключ секретен. Он не решает:

Управление ключами. Если вы отправляете пароль вместе с файлом по email, AES-256 не добавляет никакой защиты.
Компрометацию конечной точки. Вредоносная программа, читающая открытый текст до шифрования, полностью обходит шифр.
Ошибки реализации. Атаки BEAST, CRIME и Lucky13 2018 года были направлены против реализаций TLS, а не против самого AES.
Атаки по сторонним каналам. Анализ кеш-тайминга и потребления мощности позволял извлекать ключи AES с ограниченных устройств. AES-NI в значительной мере устраняет это на десктопах.

AES-256 также не доказывает, кто отправил файл. Для этого используйте цифровые подписи на основе Ed25519 или ECDSA.

Почему «военный уровень» — во многом маркетинг

Фраза получила распространение потому, что АНБ одобрило AES-256 для данных категории TOP SECRET в 2003 году согласно CNSSP-15. Это реальный факт, но ему уже более 20 лет — AES-128 одобрен для категории SECRET и для большинства гражданских задач ничем не хуже. Переход с 128 до 256 бит — это страховка от будущего развития квантовых вычислений: алгоритм Гровера теоретически вдвое снижает стойкость симметричного ключа, уменьшая эффективную стойкость AES-256 до 128 бит, — что по-прежнему безопасно.

На практике AES-256 потребляет примерно на 40% больше процессорного времени, чем AES-128 при наличии AES-NI, и поддерживается повсеместно, поэтому стал стандартом даже там, где 128 бит было бы достаточно.

Как проверить, что сервис действительно использует AES-256-GCM

Три способа проверить:

Прочитайте техническую документацию по безопасности. Достоверные сервисы (Tresorit, Proton Drive, SwissTransfer, HexaTransfer) публикуют точный режим и обработку IV.
Изучите исходный код клиента. Откройте DevTools, найдите в JavaScript-бандле AES-GCM или aes-256-gcm. Это должно быть явно указано.
Проверьте независимые аудиты. Cure53, NCC Group и Trail of Bits публикуют аудиты с указанием проверенных алгоритмов.

Красные флаги: «банковское шифрование» без указания режима, «фирменный алгоритм» любого рода, упоминание AES-128-ECB.

Применяйте знания на практике

При отправке конфиденциального файла сегодня: выбирайте сервис, явно указывающий AES-256-GCM, использующий 96-битный случайный IV на файл и выполняющий шифрование в браузере, а не на сервере. Дополните это парольной фразой длиной от 16 символов, получаемой через Argon2id или PBKDF2 с не менее 600 000 итераций.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.