Режимы блочного шифрования

2011 год. Исследователи Thai Duong и Juliano Rizzo демонстрируют BEAST - атаку на CBC в TLS 1.0. Они расшифровывают cookie в реальном времени прямо в браузере. Уязвимость существовала 10 лет. Причина: предсказуемый IV в CBC. Один неправильный режим шифрования - и безопасность рассыпается несмотря на 'правильный' AES.

• TLS 1.3 удалил CBC полностью - остался только GCM и ChaCha20-Poly1305, оба AEAD
• WireGuard использует исключительно ChaCha20-Poly1305 - один алгоритм, ноль исторического груза, минимальная поверхность атаки
• Signal Protocol использует AES-256-CTR для сообщений + отдельный HMAC-SHA256 - Encrypt-then-MAC как текущий стандарт pre-GCM

ECB: почему шифрование пикселей - плохая идея

Electronic Codebook (ECB) - наивный режим: каждый 16-байтовый блок шифруется независимо одним ключом. Результат детерминирован: одинаковый plaintext всегда даёт одинаковый ciphertext. Это катастрофа.

Знаменитый пример: зашифровать Linux Tux пингвина через AES-ECB. Пространство цветов пикселей ограничено - повторяющиеся блоки пикселей дают повторяющиеся блоки ciphertext. Контуры пингвина остаются видимы в зашифрованном изображении. Шифрование есть. Безопасности нет.

ECB небезопасен при любых данных с паттернами. HTTP-заголовки, JSON-структуры, SQL-запросы, изображения - всё это имеет повторяющиеся паттерны. Практическая атака: Cut-and-Paste. Если зашифрованное сообщение состоит из ECB-блоков, их можно переставить, изменив смысл без знания ключа. Известный кейс - атака на Oracle padding с ECB.

ECB никогда не используется в современных протоколах. Но он до сих пор существует в библиотеках 'для совместимости'. Если видишь AES/ECB в code review - это красный флаг. Минимум должен быть CBC с случайным IV или, лучше, GCM.

CBC: XOR с предыдущим блоком

Cipher Block Chaining (CBC) решает ECB-проблему через chaining: каждый plaintext-блок XOR'ится с предыдущим ciphertext-блоком перед шифрованием. Первый блок XOR'ится с Initialization Vector (IV) - случайным числом, которое передаётся вместе с ciphertext.

CBC решает ECB-проблему, но создаёт новую: шифрование строго последовательное (нельзя шифровать блоки параллельно). Расшифрование - параллельное. Атака BEAST (2011) показала уязвимость CBC в TLS 1.0 при предсказуемом IV. POODLE (2014) - атака на padding CBC в SSL 3.0. В TLS 1.3 CBC убрали совсем.

Padding oracle attack - классика против CBC. Если сервер возвращает разные ошибки для 'неверный padding' и 'неверная подпись', атакующий может по-одному восстановить всё сообщение, послав O(256N) запросов, где N - число блоков. Защита: всегда проверять MAC до unpadding (Encrypt-then-MAC, не MAC-then-Encrypt).

CTR: блочный шифр как поточный

Counter Mode (CTR) превращает блочный шифр в поточный. Вместо шифрования данных напрямую, шифруется счётчик: AES(nonce || counter) = keystream. Затем keystream XOR данные. AES никогда не расшифровывает - только шифрует. Расшифрование идентично шифрованию.

CTR полностью параллелен: все блоки keystream можно вычислить независимо. Это означает hardware AES-NI инструкции дают максимальный throughput. Intel AES-NI на современном CPU даёт 40+ Гбит/с для AES-128-CTR. CTR позволяет произвольный доступ к потоку: чтобы расшифровать байт #1000000, не нужно расшифровывать первые 999999.

Критическое правило CTR: nonce никогда не должен повторяться с одним ключом. Если nonce повторится, XOR двух ciphertext'ов = XOR двух plaintext'ов. При известном одном plaintext, второй восстанавливается элементарно. Это произошло с WEP (Wi-Fi 1999) - IV всего 24 бита, повторяется через ~16M пакетов.

OFB и CFB: feedback-режимы и их ниши

Output Feedback (OFB) и Cipher Feedback (CFB) - исторически важные режимы, сейчас практически вытесненные CTR и GCM. Но они появляются в embedded и legacy-системах, поэтому понять их стоит.

OFB генерирует keystream независимо от данных - как CTR. Разница: CTR использует счётчик, OFB рекурсивно применяет AES к предыдущему выходу. OFB строго последовательный. CFB 'кусает' данные по N бит (8, 64, 128) - удобно для протоколов с нефиксированным размером блока. CFB-8 использовался в ранних версиях SSH.

Практический совет 2024: для нового кода - только AES-GCM или ChaCha20-Poly1305 (AEAD). Если нужен CTR без аутентификации - только для специфичных протоколов где MAC выносится наружу. CBC - только для совместимости с legacy. OFB/CFB - почти никогда в новом коде.

Связанные темы

Режимы шифрования - ключевой элемент стека криптографических протоколов:

• AES — Базовый блочный шифр для всех режимов
• AEAD (GCM, ChaCha20-Poly1305) — Современные режимы с аутентификацией
• TLS — Реальное применение режимов шифрования

Ключевые идеи

• ECB небезопасен: одинаковые блоки -> одинаковый ciphertext, паттерны данных видны
• CBC решает ECB через chaining, но уязвим к padding oracle и BEAST - в TLS 1.3 удалён
• CTR: блочный шифр как поточный, полная параллельность, произвольный доступ, nonce нельзя повторять
• Для нового кода - только AEAD (GCM или ChaCha20-Poly1305). CBC/CTR только с явным MAC

Вопросы для размышления

• Почему nonce-reuse в CTR катастрофичен, а IV-reuse в CBC лишь ослабляет безопасность?
• Как атака BEAST использовала предсказуемый IV, и что именно поменяли в TLS 1.1 для защиты?
• Когда CTR без MAC приемлем, и какой слой тогда должен обеспечивать integrity?

Связанные уроки

• crypto-14-aes — AES - базовый блочный шифр для всех режимов
• crypto-16-aead — AEAD строится поверх режимов (GCM = CTR + auth)
• crypto-32-tls — TLS использует CBC и GCM как cipher suites
• crypto-05-information-theory — Информационная теория объясняет почему ECB небезопасен
• net-23-https-tls