ГОСТ Р 34.10-2012 и «Стрибог» в CMS: проект ТК26¶

Что это за документ¶

На сайте КриптоПро доступен 37-страничный документ «Использование алгоритмов ГОСТ 28147-89, ГОСТ Р 34.11 и ГОСТ Р 34.10 в криптографических сообщениях формата CMS». На обложке указано: «Методические рекомендации (проект)», «проект первой редакции», апрель 2014 года. В разделе 1.1 авторы прямо указывают, что это предварительный документ с установленным сроком актуальности до января 2015 года.

Поэтому мы используем его как подробное описание предложенного профиля совместимости, а не представляем как утверждённый и актуальный обязательный стандарт. Перед нормативным применением нужно проверять наличие последующей принятой редакции и требования конкретной системы документооборота.

Что меняется относительно RFC 4490¶

Появляются криптографические примитивы ГОСТ Р 34.10-2012 с длинами ключа 256/512 бит и ГОСТ Р 34.11-2012 с хэшами 256/512 бит. Проект последовательно описывает:

Идентификаторы хэшей и расположение результата в DigestedData/подписанных атрибутах (раздел 4).
Значения SignerInfo.signatureAlgorithm и формат подписи (раздел 5).
VKO, управление сеансовыми ключами и RecipientInfo (раздел 6).
Шифрование содержимого ГОСТ 28147-89 с iv и encryptionParamSet (раздел 7).
HMAC-Стрибог для AuthenticatedData (раздел 8).
Объявления алгоритмов в S/MIME (раздел 9).
Требования по безопасности, совместимости и контрольные примеры (разделы 10–11 и приложение В).

Стрибог-256 и Стрибог-512¶

Раздел 4 задаёт OID 1.2.643.7.1.1.2.2 для Стрибог-256 и 1.2.643.7.1.1.2.3 для Стрибог-512. Размеры соответствующего хэша — 32 и 64 байта. Для AlgorithmIdentifier в этом проекте указано обязательное значение NULL в параметрах; в других современных спецификациях правила кодирования полей могут отличаться, поэтому нужно читать профиль именно той структуры, которую формирует приложение.

Разница между 256- и 512-битным хэшем — не только количество символов в диагностическом выводе. В документах указывается соответствие разновидности хэширования конкретному варианту ГОСТ-подписи.

Подписи ГОСТ Р 34.10-2012¶

В разделе 5 для 256-битного варианта определена подпись длиной 64 байта; для 512-битного — 128 байт. Оба представления используют порядок s || r, где каждая компонента записана big-endian и занимает половину длины подписи.

ГОСТ Р 34.10-2012/256
  s: 32 байта | r: 32 байта  → 64 байта

ГОСТ Р 34.10-2012/512
  s: 64 байта | r: 64 байта  → 128 байт

Аналогичные правила представления подписей для сертификатов и инфраструктуры PKI дополнительно описаны в RFC 9215. Это не означает, что 256-битная подпись содержит 256 бит результата: в ней две компоненты, а суммарная длина — 512 бит.

Ключи: VKO и перенос содержимого¶

Документ описывает обмен ключами по VKO ГОСТ Р 34.10-2012 и упаковку сеансового ключа алгоритмом ГОСТ 28147-89. В схемах фигурируют CEK, KEK, UKM, KeyAgreeRecipientInfo, KeyTransRecipientInfo и Gost28147-89-EncryptedKey. Для совместимости важны и математические операции, и точное расположение полей в ASN.1.

В приложении А сопоставлены способы защиты ключей GOST 28147-89 Key Wrap и CryptoPro Key Wrap из RFC 4357; приложение Б разбирает преобразования ключевого материала. Понимание этих разделов полезно при сравнении файлов, созданных разными российскими СКЗИ.

Что проект не утверждает¶

Наличие ГОСТ Р 34.10-2012 в сертификате ещё не доказывает, что приложение поддерживает все режимы шифрования CMS, и наличие «Кузнечика» в ядре не означает поддержку CMS-обёртки для ключей. Равным образом проект не является свидетельством сертификации конкретного программного продукта.

От проекта к нормативному профилю: хронология¶

2006: RFC 4490 ──> исторические ГОСТ-94/2001 + ГОСТ 28147 в CMS
         │
2012: ГОСТ Р 34.10 и ГОСТ Р 34.11 ──> новые семейства подписи и хэша
         │
2014: проект ТК26 ──> варианты CMS/OID для ГОСТ-2012 (не окончательная норма)
         │
2019: Р 1323565.1.025-2019 ──> действующие российские рекомендации по CMS
         │
2022: RFC 9215 ──> ГОСТ-2012 в X.509, сертификатах и CRL

Ключевое различие: проект 2014 года полезен как технический исторический материал. Его нельзя цитировать в документации НАЙС.ОС как единственный источник обязательных современных требований без сверки с официальной карточкой рекомендаций 2019 и полным текстом применимого документа. На октябрь 2026 года карточка Росстандарта указывает статус «Действует» и дату введения 01.12.2019.

Четыре уровня совместимости для ГОСТ-2012 CMS¶

Уровень	Требование	Что будет при несоответствии
Криптографический	Совпадение алгоритма, кривой и размера хэша	Ошибка подписи/получения ключа
Форматный	Совпадение OID, параметров, endian и DER	Не распознаётся `AlgorithmIdentifier`
Контейнерный	Совпадение CMS-типа, атрибутов, `RecipientInfo`	Данные декодируются, но операция не выполняется
Доверие/политика	X.509, сроки, назначение, CRL/OCSP	Подпись верна, но документ не принят

Не полагайтесь только на текстовую метку «ГОСТ-2012»: 256 и 512 — самостоятельные профили. Важны и длина хэша, и параметры кривой, и способ представления ключа в ASN.1. Для криптографических операций см. подпись 256, подпись 512, Стрибог-256, Стрибог-512, VKO.

Что не следует брать из проекта без проверки¶

Отдельные проектные OID и соглашения о параметрах, если действующий документ или межвендорный профиль их уточнил.
Формулировки micalg и MIME-тегов как доказательство истинного алгоритма: решающим остаётся CMS/ASN.1 и криптографическая проверка.
Конкретные примеры SignerInfo или RecipientInfo как универсальный шаблон для любого приложения: разные профили могут предъявлять дополнительные требования.
Пример успешного взаимодействия с одним поставщиком как гарантию соответствия требованиям государственного регулирования.

Как оформлять новую интеграцию¶

В техническом задании фиксируйте название нормативного профиля, версию библиотеки, перечень допустимых алгоритмов, OID и наборов параметров, форматы attached/detached, требования к сертификатам, атрибутам, CRL/OCSP и отрицательные тесты. Проверьте и документируйте обмен в обоих направлениях.

См. матрицу межоперабельности, политику валидации, реальные настройки OpenSSL и справочник OID.

Источники¶

Маршрут чтения: Российский профиль CMS → SignedData → EnvelopedData