MGM — аутентифицированное шифрование¶
Источник описания и статус реализации
Алгоритм, профиль стандарта и программная поддержка — три разных уровня. RFC Editor публикует многие описания ГОСТ как Informational / Independent Submission, а не как консенсусный стандарт IETF. Наличие RFC не свидетельствует о сертификации СКЗИ и не доказывает поддержку алгоритма каждым приложением НАЙС.ОС. Проверяйте установленную версию и подтверждённые испытания.
Назначение и параметры¶
| Характеристика | Значение |
|---|---|
| Класс | Режим AEAD |
| Размер блока / результата / профиль | Блок 64 или 128 бит |
| Ключевой материал | Ключ базового шифра |
| Основной источник | RFC 9058 |
Как устроен алгоритм и что он гарантирует¶
MGM (Multilinear Galois Mode) объединяет конфиденциальность и проверку целостности/аутентичности данных в конструкции AEAD. На вход подаются открытый текст, дополнительные аутентифицируемые данные (AAD), nonce и секретный ключ. На выходе — шифротекст и тег. Получатель должен проверить тег до выдачи расшифрованных данных приложению; ошибка тега означает отказ в принятии сообщения.
MGM работает поверх базового блочного шифра, например Кузнечика или Магмы. Поэтому «MGM» без указания базового шифра, длины тега, правил nonce и профиля ключей — недостаточная спецификация.
Критически важна уникальность nonce в установленном профиле: повтор при одинаковом ключе может разрушить гарантии безопасности. Точная структура nonce и способы формирования ключей в IKEv2/ESP задаются RFC 9227; нельзя подменять их собственным счётчиком.
MGM не равно GCM, а MGM-KTREE — это протокольная композиция, включающая управление ключевым материалом, а не название отдельного блочного шифра.
Реализация в НАЙС.ОС: что подтверждено и что проверять¶
- Применяется в профилях
KUZNYECHIK_MGM_KTREEиMAGMA_MGM_KTREERFC 9227. - В испытанном НАЙС.ОС strongSwan подтверждён первый из них;
swanctl --list-sasпоказывает реальное согласованное предложение. - Для тестовых векторов используйте приложение к RFC 9058, а не случайный зашифрованный файл.
Проверка и критерии приёмки¶
Перед эксплуатацией получите перечень реальных возможностей целевого пакета, а не доверяйте абстрактной таблице криптографии. Положительный тест должен соответствовать выбранному профилю, формату ключей, параметрам и протоколу; отрицательный тест должен демонстрировать отказ при неверном ключе, повреждённых входных данных или неверном теге (если соответствующая защита предусмотрена). Для сетевых профилей отдельно проверьте отказ аутентификации, границы ключевой ротации и предотвращение обхода туннеля.
Эксплуатация и совместимость¶
- Матрица статусов алгоритмов: стандарт, имя системной реализации, подтверждённый тест.
- Использование ГОСТ в ядре Linux, OpenSSL, IKEv2/strongSwan, шифрование дисков.
- OID и параметры, форматы ключей и подписи, векторы испытаний.
- Правила безопасности и полный каталог RFC.
Связь с документами и форматами CMS¶
AEAD в CMS и EnvelopedData · Модель угроз контейнеров. Для сетевого IKEv2 и ядра правила применения задаются отдельно.