Словарь ГОСТ-криптографии и статус технических документов¶
С 1 января 2026 года действует ГОСТ Р 34.14-2025 «Информационная технология. Криптографическая защита информации. Термины и определения», утверждённый приказом Росстандарта № 1070-ст от 17 сентября 2025 года. Стандарт устанавливает термины для работ в области криптографической защиты информации. Он введён впервые и пришёл на смену временной терминологической базе ПНСТ 799-2022.
При написании документации НАЙС.ОС следует пользоваться единообразными русскими терминами, а аббревиатуры из RFC раскрывать при первом упоминании. Приведённые ниже пояснения — учебные, а не буквальное воспроизведение определений ГОСТ Р 34.14-2025.
| Термин | Что означает в руководствах |
|---|---|
| Блочный шифр | Базовое преобразование блока данных по ключу: «Магма», «Кузнечик» |
| Режим работы | Способ применения блочного шифра к сообщениям/секторам: CBC, CTR, XTS, MGM, DEC |
| Хэш-функция | Получение фиксированного дайджеста: «Стрибог»-256/512 |
| Имитовставка (MAC) | Проверка подлинности и целостности с секретным ключом |
| Электронная подпись | Криптографическое подтверждение с использованием закрытого ключа и проверки открытым |
| Сертификат X.509 | Связь данных субъекта с открытым ключом, подписанная УЦ |
| Ключевой материал | Данные, из которых формируются используемые криптографические ключи |
| Обмен/согласование ключей | Получение совместного секрета или передача защищённого ключа |
| CMS | Универсальный формат защищённого криптографического сообщения |
| LUKS2 | Формат метаданных и управления ключами зашифрованного блочного тома Linux |
| Crypto API | Интерфейс криптографических операций ядра Linux |
Классификация источников¶
Национальный стандарт ГОСТ Р. На него можно ссылаться как на российский стандарт, но необходимо проверять актуальную редакцию и область применения.
Рекомендации по стандартизации Р 1323565. Это самостоятельные опубликованные документы. Их статус («действует» или «заменён») проверяется по официальной карточке Росстандарта. Не следует автоматически объявлять рекомендации общеобязательным законом для любого ПО.
RFC Standards Track. Документы опубликованы в рамках процесса IETF; категория Proposed Standard не тождественна российскому ГОСТ. Например, RFC 10002–10004 определяют общий CMC, не специальный профиль ГОСТ.
RFC Informational / Independent Submission. Полезные проверяемые технические форматы, но публикация не означает одобрение IETF российских алгоритмов. К ним относятся RFC 9367, 9548 и 9558.
Проект / Internet-Draft. Технический рабочий материал: его нельзя выдавать за действующую утверждённую версию. Пример — PDF ТК26 2014 года по CMS.
Реализовано в НАЙС.ОС. Техническое утверждение, подтверждаемое кодом, сборкой и испытаниями конкретной системы. Утверждённый документ без реализации не превращается в поддерживаемую функцию продукта.
Актуализация терминологии¶
Для новых страниц используйте единую цепочку: понятие → алгоритм → режим → протокол → реализация → испытание. Слова «ГОСТ из коробки» допустимы применительно к конкретным поставляемым функциям ОС, но не могут означать все существующие ГОСТ-профили TLS, CMS, DNSSEC, IPsec или УЦ.
Источники: ГОСТ Р 34.14-2025 — официальный фонд; публикация ТК26 о введении стандарта; каталог ТК26.
Обязательные языковые и технические различия¶
Алгоритм / режим / протокол. «Кузнечик» — блочный шифр; MGM — режим аутентифицированного шифрования; TLS 1.3 — протокол, в котором конкретный набор шифров может использовать MGM. Одинаковое слово GOST в логах не подтверждает равенства всех трёх сущностей.
Шифрование / подпись / хэш. DNSSEC применяет подписи и хэш, а не шифрует DNS-ответ; X.509 содержит открытые ключи и подписи CA, а не шифрует сертификат; XTS защищает конфиденциальность блока данных, но сам по себе не обеспечивает аутентичность содержимого.
Верификация / доверие / регуляторное соответствие. Математически верная подпись может не проходить проверку цепочки; доверенный сертификат может быть отозван; рабочий протокол может не иметь сертификата СКЗИ. В инструкциях для пользователей НАЙС.ОС все три понятия должны сопровождаться разными проверками.
Ключевой материал / ключ шифрования / пароль. Пароль должен преобразовываться в ключевой материал согласно профилю и политике. Защита PFX не равна режиму шифрования данных LUKS2. VKO формирует согласованный секрет, но не заменяет операции проверки сертификатов.
Мини-словарь параметров и кодирования¶
| Термин | Где встретится | На что обратить внимание |
|---|---|---|
| OID | CMS, X.509, PKCS#12 | Одинаковое текстовое название с разными OID не гарантирует обмен |
| DER | X.509, CMS | Однозначность кодирования; подписываются конкретные байты |
| UKM | VKO и обмен ключами | Значение и формат должны соответствовать профилю |
| nonce/IV | MGM, CTR, TLS, ESP | Уникальность, размер, порождение, ограничения повторного использования |
| salt | PBKDF и ESP | Разные назначения; параметры не взаимозаменяемы |
| CRL | PKI, IKEv2, CMS | Подпись УЦ, актуальность, серия, политика отказа |
| PFS | IKEv2 | Свойство согласования ключей при конкретном профиле/параметрах |
Расширенное объяснение: словарь алгоритмов, теория CMS, режимы и AEAD, проверка PKI, терминологический ГОСТ.