Следующий рубеж: CMS EnvelopedData между НАЙС.ОС и КриптоПро¶
После успешной локальной проверки GPGSM остаются два независимых испытания: КриптоПро на macOS шифрует, НАЙС.ОС расшифровывает; затем НАЙС.ОС шифрует, а КриптоПро расшифровывает. На 24 октября 2026 года результатов обоих опытов нет. Ниже — воспроизводимая методика, а не отчёт о якобы выполненном обмене.
Условия¶
Для каждого направления нужен свой закрытый ключ на стороне получателя. При этом отправитель получает только открытый X.509-сертификат адресата.
| Направление | Кто хранит закрытый ключ | Что передаём отправителю |
|---|---|---|
| E-02: CryptCP → GPGSM | НАЙС.ОС | niceos-lab-public.cer |
| E-03: GPGSM → CryptCP | Mac с тестовым CryptoPro CSP | только открытый сертификат лабораторного получателя Mac |
Не используйте действующий ключ КЭП на Рутокене в роли дешифратора тестового сообщения: он может не поддерживать требуемую операцию или использование для шифрования может противоречить назначению ключа. Отдельные лабораторные сертификаты должны быть пригодны для keyAgreement / keyEncipherment с учётом профиля CSP.
E-02. КриптоПро создаёт EnvelopedData для НАЙС.ОС¶
Шаг 1 — экспорт сертификата получателя на НАЙС.ОС:
LAB=/root/gost-cms-test/lab
openssl x509 -in "$LAB/niceos-lab.crt.pem" \
-outform DER -out "$LAB/niceos-lab-public.cer"
Перенесите niceos-lab-public.cer на Mac. Не переносите .key или .p12.
Шаг 2 — выбор профиля в CryptCP:
На Mac CryptCP 5.0 предоставляет -encr и -encrf. Настройте шифрование на открытый сертификат НАЙС.ОС, а для первоначальной проверки выбирайте поддерживаемый данной версией исторический шифр содержимого ГОСТ 28147-89, OID 1.2.643.2.2.21, если конкретная сборка CryptCP допускает его выбор.
Вариант командной строки, который следует сначала подтвердить на установленной версии:
CRYPTCP=/opt/cprocsp/bin/cryptcp
"$CRYPTCP" -encrf \
-f "$HOME/gost-interop/niceos-lab-public.cer" \
-encryptionalg 1.2.643.2.2.21 \
"$HOME/gost-interop/plain.txt"
Статус команды: это предлагаемый тест, не зафиксированный успешный запуск. Если CryptCP отвергает флаг или профиль, сохраните сообщение об ошибке и используйте «Инструменты КриптоПро» для выбора сертификата и режима, вместо подбора случайных опций.
Шаг 3 — расшифрование на НАЙС.ОС:
LAB=/root/gost-cms-test/lab
# Замените имя на фактическое имя полученного DER-CMS файла.
gpgsm --homedir "$LAB/gnupg" \
--output "$LAB/decrypted-from-mac.txt" \
--decrypt "$LAB/from-mac.p7e"
rc=$?
echo "Decrypt rc: $rc"
[ "$rc" -eq 0 ] && sha256sum "$LAB/decrypted-from-mac.txt"
Сравнивайте sha256sum с оригиналом на macOS через shasum -a 256, или побайтово после копирования тестового исходного текста.
E-03. НАЙС.ОС создаёт EnvelopedData для КриптоПро¶
Шаг 1 — лабораторный сертификат Mac: создайте отдельную тестовую пару с закрытым ключом, доступным CryptCP для расшифрования. Экспортируйте только открытый сертификат. Не используйте для этого действующую КЭП.
Шаг 2 — импорт открытого сертификата Mac в GPGSM:
LAB=/root/gost-cms-test/lab
gpgsm --homedir "$LAB/gnupg" \
--import "$LAB/mac-lab-public.cer"
gpgsm --homedir "$LAB/gnupg" --list-keys
Шаг 3 — шифрование для получателя Mac:
MAC_FPR='ПОЛНЫЙ_ОТПЕЧАТОК_ТЕСТОВОГО_ПОЛУЧАТЕЛЯ_MAC'
gpgsm --homedir "$LAB/gnupg" \
--always-trust --cipher-algo GOST28147 \
--recipient "$MAC_FPR" \
--output "$LAB/to-mac.p7e" \
--encrypt "$LAB/plain.txt"
--always-trust применяется здесь только к искусственному получателю в изолированном стенде. Поставьте CryptCP на Mac расшифровать to-mac.p7e на соответствующий лабораторный закрытый ключ, затем сравните файл с исходным. Синтаксис команды cryptcp -decr или -decrf зависит от типа входного файла, способа установки ключа и версии CryptCP; точную команду следует закреплять после первого успешного запуска, а не выдавать непроверенный набор флагов за подтверждённый.
Что фиксировать при отказе¶
- Содержимое открытого X.509 (
Signature Algorithm,Public Key Algorithm,Key Usage, OID кривой). - Тип CMS
EnvelopedData, число получателей, OID шифра содержимого, описаниеRecipientInfo, тип KeyTransport/KeyAgreement. - Код завершения и первое существенное сообщение об ошибке без DN с персональными сведениями.
- Версии обеих сторон, пути к тестовым файлам и SHA-256 исходного текста. Не включайте пароль и приватные ключи.
Успешная расшифровка одного направления ещё не закрывает другое. Для общего заявления о взаимной совместимости надо завершить обе проверки, а затем выполнить отрицательные тесты повреждённого транспорта ключа. RFC 4490 описывает исторические KTRI/KARI и ГОСТ28147, но он не доказывает, что любая современная сборка автоматически поддерживает конкретный профиль.