AES-CCM:
стандартный выбор для аутентифицированного шифрования
Режим CCM (Counter with CBC-MAC) является одним из
наиболее устойчивых и практичных вариантов в контексте использования
симметричного шифрования в SJCL. Он сочетает в себе:
- шифрование в режиме CTR (Counter Mode)
- аутентификацию данных через CBC-MAC
В SJCL он реализован как sjcl.mode.ccm и применяется
вместе с AES-256 как базовым блоковым шифром.
Ключевая особенность CCM заключается в том, что он обеспечивает
конфиденциальность и целостность одновременно, исключая
необходимость отдельного HMAC.
Особенности применения CCM
- Требует уникальный nonce для каждого сообщения
- Поддерживает дополнительные аутентифицируемые данные (AAD)
- Обеспечивает защиту от подмены и модификации шифртекста
- Имеет более высокую вычислительную стоимость по сравнению с чистым
CTR
Когда использовать CCM
- Передача данных по сети, где возможны активные атаки
- Хранение чувствительных структурированных данных
- Любые сценарии, где требуется единый механизм AEAD
AES-OCB2:
высокая производительность и компактность
Режим OCB2 (Offset Codebook Mode) в SJCL реализован
как sjcl.mode.ocb2. Он относится к категории AEAD и
обеспечивает более высокую производительность по сравнению с CCM.
Главная идея OCB заключается в объединении шифрования и
аутентификации в один проход по данным, что уменьшает накладные
расходы.
Характерные свойства OCB2
- Быстрее CCM на больших объёмах данных
- Минимальная задержка при обработке блоков
- Поддержка параллелизации вычислений
- Компактный шифртекст (меньше служебных данных)
Ограничения
- Исторически связан с патентными ограничениями (в некоторых средах
это критично)
- Менее распространён в новых криптографических стандартах
- Требует строгого контроля nonce
Когда оправдан выбор OCB2
- Высоконагруженные приложения с большими потоками данных
- Клиентские приложения, где важна скорость шифрования
- Системы, где допустимы патентные риски
AES-CBC + HMAC:
классическая композиция
Режим CBC (Cipher Block Chaining) в SJCL реализован
как sjcl.mode.cbc. Сам по себе он не обеспечивает
аутентификацию, поэтому используется в связке с HMAC.
Типичная схема выглядит как:
- шифрование: AES-CBC
- контроль целостности: HMAC-SHA256
Ключевая архитектурная
особенность
Это не AEAD-режим, а композиция двух примитивов, где
безопасность зависит от корректной реализации порядка операций.
Риски при использовании CBC
- Уязвимость к padding oracle при ошибках обработки исключений
- Отсутствие встроенной защиты целостности
- Необходимость строгого разделения ключей (encryption key / MAC
key)
Когда используется CBC + HMAC
- Совместимость с устаревшими системами
- Интеграция с протоколами, где AEAD недоступен
- Сценарии, где требуется явное разделение криптографических
примитивов
AES-CTR:
потоковое шифрование без аутентификации
Режим CTR (Counter Mode) в SJCL реализуется как
sjcl.mode.ctr. Он превращает блочный шифр AES в
потоковый.
Основные свойства
- Отсутствие блокировки данных (stream-like processing)
- Высокая скорость
- Простота реализации
Критическое ограничение
CTR не обеспечивает целостность данных. Любое
изменение шифртекста приводит к предсказуемым изменениям в открытом
тексте, что делает его непригодным для небезопасных каналов без
дополнительной защиты.
Использование CTR
оправдано в случаях
- Внутренние системы с доверенной средой передачи
- Построение более сложных конструкций (например, в связке с
HMAC)
- Потоковое шифрование больших данных при наличии внешней
аутентификации
Сравнение режимов
по критическим параметрам
Аутентификация данных
- CCM — встроенная
- OCB2 — встроенная
- CBC — отсутствует (требуется HMAC)
- CTR — отсутствует
Производительность
- CTR — максимальная скорость
- OCB2 — высокая скорость с аутентификацией
- CCM — средняя скорость
- CBC + HMAC — ниже среднего из-за двойной обработки
Устойчивость к ошибкам
реализации
- CCM — высокая
- OCB2 — высокая при корректной работе с nonce
- CBC + HMAC — зависит от архитектуры
- CTR — низкая без дополнительной защиты
Критические требования к
nonce и IV
Во всех современных режимах SJCL безопасность зависит от уникальности
nonce:
- повтор nonce в CCM или OCB2 приводит к компрометации ключа
- в CTR повтор nonce эквивалентен повторному использованию потока
ключа
- CBC требует корректного IV для первого блока
Практическое следствие: генерация nonce должна опираться на
криптографически стойкий источник случайности
(sjcl.random).
Выбор режима в
зависимости от класса задачи
Каналы связи с
потенциальным атакующим
- CCM как базовый стандарт
- OCB2 при высокой нагрузке
Локальное шифрование данных
- CCM для универсальности
- CBC + HMAC при необходимости совместимости
Потоковая обработка больших
данных
- CTR при наличии внешней аутентификации
- OCB2 при необходимости встроенной защиты
Ошибки архитектурного
выбора режимов
Часто встречающиеся проблемы:
- использование CTR без MAC-слоя
- повтор nonce при генерации из timestamp
- попытка заменить AEAD комбинацией CBC без HMAC
- хранение IV вместе с ключом в небезопасных структурах
- игнорирование различий между шифрованием и аутентификацией
Практическая модель
принятия решения
Выбор режима в SJCL всегда сводится к трём параметрам:
- необходимость аутентификации
- производительность на целевом объёме данных
- требования совместимости с внешними системами
Комбинация этих факторов определяет использование CCM как
универсального варианта, OCB2 как оптимизированного решения, CBC + HMAC
как совместимого варианта и CTR как базового строительного блока для
специализированных схем.