Аутентифицированное шифрование (AEAD)

До AEAD разработчики комбинировали шифрование и MAC вручную. И делали ошибки: MAC-then-Encrypt (уязвим к padding oracle), Encrypt-and-MAC (утечка данных через MAC), неправильный порядок ключей. Lucky Thirteen, BEAST, POODLE - все эксплуатировали неправильную комбинацию. AEAD объединил оба свойства в атомарный примитив, который сломать сложнее.

• TLS 1.3 запретил все cipher suites без AEAD - только AES-GCM и ChaCha20-Poly1305, никаких CBC
• WireGuard выбрал ChaCha20-Poly1305 как единственный алгоритм - нет negotiation, нет downgrade, код умещается в 4000 строк
• Signal шифрует каждое сообщение отдельным ключом с ChaCha20-Poly1305 - forward secrecy на уровне сообщений

GCM: CTR + GHASH в одном примитиве

Galois/Counter Mode (GCM) стал стандартом AEAD после 2007 года. Идея: взять CTR для confidentiality, добавить GHASH для integrity, объединить в атомарный примитив. Atakующий не может модифицировать ciphertext незамеченным - 128-битный authentication tag сломается.

GCM состоит из двух частей: AES-CTR шифрует данные (с nonce/counter), GHASH аутентифицирует ciphertext + Additional Authenticated Data (AAD). AAD - это данные, которые нужно аутентифицировать, но не шифровать: IP-заголовок, версия протокола, session ID. Если AAD изменится - тег невалиден.

GHASH работает в поле Galois GF(2^128). Это полиномиальное хеширование - каждый блок данных умножается на ключ H = AES(key, 0^128) в поле. Математически лаконично. Практически: Intel реализовал PCLMULQDQ инструкцию для GF(2^128) умножения. На современном CPU AES-256-GCM даёт 20+ Гбит/с.

Nonce в GCM должен быть уникален для каждого сообщения с одним ключом. При nonce reuse атака восстанавливает ключ аутентификации H за две операции XOR. TLS генерирует nonce как sequence number, чтобы гарантировать уникальность. Если используешь random 96-битный nonce - birthday bound 2^48 сообщений до вероятной коллизии.

ChaCha20-Poly1305: AEAD без AES hardware

2014 год. Daniel J. Bernstein и Tanja Lange. ChaCha20-Poly1305 стал официальным cipher suite в TLS 1.2 (RFC 7539) и обязательным в TLS 1.3. Причина: миллиарды Android-устройств без AES-NI hardware - на них GCM в 3x медленнее ChaCha20.

ChaCha20 - поточный шифр на ARX (Add-Rotate-XOR) операциях. 20 раундов трансформации 4x4 матрицы uint32. Полностью constant-time без lookup tables - нет timing side-channel как у AES без hardware поддержки. Poly1305 - MAC на основе однозначного полиномиального хеширования над простым полем.

WireGuard использует исключительно ChaCha20-Poly1305. Одна cipher suite, никаких negotiation, минимальная поверхность атаки. Google Chrome переключился на ChaCha20-Poly1305 как предпочтительный cipher для мобильных соединений в 2014 году. Signal Protocol стандартизировал его для всех сообщений.

GCM vs ChaCha20-Poly1305: с AES-NI (desktop, server) GCM быстрее. Без AES-NI (мобильные, IoT, старые ARM) ChaCha20 быстрее. Оба одинаково безопасны при правильном использовании. TLS 1.3 поддерживает оба. Выбор зависит от платформы.

CCM: AEAD для IoT и малых устройств

Counter with CBC-MAC (CCM) - AEAD режим для ограниченных ресурсов. Использует AES как единственный примитив для обоих слоёв: CBC-MAC для аутентификации, CTR для шифрования. Требует один проход по данным (в отличие от EAX, который требует два).

CCM - обязательный cipher suite в IEEE 802.15.4 (Zigbee, Thread), Bluetooth Low Energy (AES-CCM), IEEE 802.11i (Wi-Fi WPA2 с CCMP). На микроконтроллерах без float - CCM оптимален: только целочисленные операции, единственный AES-движок на обе функции.

CCM не подходит для streaming: нужно знать длину данных для формирования заголовка CBC-MAC. GCM работает со streaming. Для TLS (где размер записи известен) оба подходят. Для больших файлов без известного размера - только GCM или ChaCha20.

Ловушки AEAD: как сломать правильный примитив

AEAD примитивы безопасны только при правильном использовании. Три класса ошибок убивают безопасность даже при правильном алгоритме.

Timing side-channel при верификации тега - реальная атака. Если `tag_received == tag_computed` проверяется по-байтово и возвращает false при первом несовпадении, атакующий измеряет время ответа и угадывает тег по одному байту. Защита: constant-time comparison (Python `hmac.compare_digest`, C `timingsafe_memcmp`).

Lucky Thirteen (2013) - атака на MAC-then-Encrypt через timing. SSL/TLS CBC+HMAC при расшифровании проверял padding перед MAC. Длина padding влияла на время ответа. Атака восстанавливала данные за 223 запроса. Переход на AEAD (GCM) устранил класс атак полностью.

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

AEAD - финальная точка в симметричном шифровании перед протокольным уровнем:

• Режимы блочного шифрования — GCM строится поверх CTR
• TLS — TLS 1.3 использует только AEAD
• HMAC и MAC — MAC-then-Encrypt альтернатива, которую AEAD заменяет

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

• AEAD дает confidentiality + integrity атомарно: невозможно расшифровать без проверки целостности
• GCM = AES-CTR + GHASH. Hardware AES-NI даёт 20+ Гбит/с. Nonce уникальность - критична
• ChaCha20-Poly1305: constant-time без lookup tables, быстрый на мобильных без AES-NI
• CCM для IoT: один AES примитив для обеих функций, но требует известной длины данных

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

• Как управлять nonce uniqueness в distributed системе, где множество нод шифруют данные одним ключом?
• Когда стоит использовать CCM вместо GCM несмотря на его ограничения?
• Что происходит если атакующий перехватит nonce - меняет ли это выбор алгоритма?

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

• crypto-15-block-cipher-modes — GCM строится поверх CTR режима
• crypto-21-hmac-mac — HMAC - альтернатива встроенному тегу AEAD
• crypto-32-tls — TLS 1.3 использует только AEAD cipher suites
• crypto-33-signal-protocol — Signal использует ChaCha20-Poly1305
• net-23-https-tls