Режимы ГОСТ и аутентифицированное шифрование: нормативная карта¶

Блочный шифр обрабатывает один блок; режим задаёт правила шифрования данных произвольной длины, генерации входных значений и обращения с ключами. Для защищённых сетевых протоколов требуется также аутентификация данных и защита от подделки. В НАЙС.ОС каждый режим описан отдельно — эта страница показывает их нормативные отношения и границы применимости.

Базовые и специализированные режимы¶

Режим или механизм	Назначение	Критические параметры	Где разбирать
ECB	Независимое шифрование блоков, демонстрационные/специализированные задачи	Раскрывает повторяющуюся структуру	ECB
CBC	Шифрование с зависимостью соседних блоков	IV, padding, защитa целостности отдельно	CBC
CTR	Поток на основе счётчика	Уникальный счётчик/nonce для ключа	CTR
CFB/OFB	Потоковые методы на базе блочного шифра	IV, порядок блоков и сегментация	CFB/OFB
MGM	AEAD: конфиденциальность + аутентичность	nonce, AAD, длина тега, пределы данных	MGM, RFC 9058
CTR-ACPKM	Шифрование с выработкой новых рабочих ключей	Размер секции, интервалы смены, nonce	CTR-ACPKM, RFC 8645
MGM-KTREE	Протокольный ESP/IKEv2-режим	Salt, nonce, дерево ключей, sequence numbers	MGM-KTREE, RFC 9227
XTS	Секторное шифрование без встроенной аутентичности	Номер сектора/tweak, два ключа	XTS, шифрование дисков
DEC	Специальная схема для носителей с блочной структурой	Профиль Р 1323565.1.042-2022	DEC

ГОСТ Р 34.13-2015 описывает базовые режимы блочных шифров. Дополнительные отечественные рекомендации и опубликованные RFC определяют особые механизмы MGM/ACPKM/DEC: нельзя считать их одной и той же конструкцией лишь из-за использования «Кузнечика».

AEAD как отдельная гарантия¶

Ключ + nonce + открытые AAD + конфиденциальный plaintext
                   |
                   v
               MGM(AEAD)
                   |
              ciphertext + tag
                   |
                   v
    получатель: проверка tag -> только затем выдача plaintext

AAD входят в расчёт целостности, но не шифруются. В протоколах туда могут входить заголовки и контекст, а в ESP — часть служебных полей. Повторение запрещённых значений nonce с тем же ключом или преждевременная выдача неаутентифицированного plaintext может уничтожить гарантии схемы. В каждом нормативном профиле проверяются длина тега, ограничение на количество сообщений и лимиты использования ключа.

Производные ключи и ротация¶

ACPKM/KDF_TREE управляют выработкой рабочего материала по заданным параметрам. Нельзя предполагать, что mgm(kuznyechik) в API сам реализует MGM-KTREE ESP: протокольный профиль дополнительно определяет формирование nonce, ключей, пакетов и обработку счётчиков. И точно так же смена ключа ESP (CHILD_SA rekey) и внутренняя выработка ключей внутри MGM-KTREE — не тождественные операции.

Безопасность выбора режима¶

Для хранения сектора обычно важны конфиденциальность и адресное связывание сектора; для сетевого протокола обязательна проверка подлинности и анти-replay. CBC/CTR без отдельной аутентификации могут быть непригодны для прямого обмена открытыми приложениями. XTS не заменяет AEAD; MGM не является безопасным выбором автоматически, если не выполнено условие уникальности nonce.

Проверка каждого режима требует тестовых векторов на границах длины блока, частичного блока, пустого AAD, ошибок тега и отказа повторного nonce — с учётом того, что не все режимы имеют одинаковый набор параметров. Для производственного кода используйте проверенные реализации, а не повторяйте псевдокод RFC без криптографического аудита.

Документы и НАЙС.ОС¶

ГОСТ Р 34.12-2015 и 34.13-2015 · RFC 9058 — MGM · RFC 8645 — ACPKM · RFC 9227 — ESP/IKEv2 · ГОСТ в Crypto API · ГОСТ IPsec · LUKS2.