GnuPG — это ключевая криптографическая система с открытым исходным кодом, лежащая в основе цифровых подписей, шифрования электронной почты, безопасности пакетов и доверенной аутентификации. Мы добавили в неё полноценную поддержку российских алгоритмов ГОСТ: ЭЦП на ГОСТ Р 34.10-2012 (256 и 512 бит), хэш-функцию ГОСТ Р 34.11-2012 (Сtribog), симметричный шифр ГОСТ 28147-89 и обёртку ключей (key wrap) на базе ГОСТ ECDH. Это значит, что теперь можно создавать и проверять подписи, шифровать данные и генерировать ключи с ГОСТ-алгоритмами напрямую — без сторонних патчей или провайдеров. Всё работает «из коробки» в Kleopatra, Thunderbird, GpgOL, RPM/DEB-сборках и CI/CD-сценариях. Разработчики получают стабильный CLI и API-интерфейс для создания ГОСТ-совместимых решений на Linux, Windows и macOS.

Применение ГОСТ-алгоритмов в GnuPG в составе НАЙС.ОС

Техническое руководство. Назначение: эксплуатация, тестирование, интеграция и диагностика ГОСТ-криптографии на уровне OpenPGP и X.509/CMS в составе GnuPG. Документ ориентирован на системных администраторов, инженеров эксплуатации и разработчиков.

---

1. Область применения

Настоящий документ устанавливает порядок применения GnuPG с поддержкой ГОСТ-алгоритмов в составе НАЙС.ОС для следующих задач:

• проверка подписи и целостности файлов и контейнеров в OpenPGP-форматах;
• проверка и формирование CMS-подписей (S/MIME), разбор X.509-сертификатов, цепочек и политик;
• диагностика совместимости с инфраструктурой российских УЦ (сертификаты, CRL, OCSP, OID/профили);
• интеграция криптоопераций в автоматизацию (скрипты, CI/CD, внутренние репозитории, артефакты поставки);
• построение стендов разработки без закупки криптопровайдера на этапе прототипирования.

Документ не заменяет требования регуляторов и не определяет юридическую применимость подписи. Документ описывает техническую эксплуатацию и методику проверок в инженерных процессах.

---

2. Нормативные ссылки и применимые требования

В инженерной практике ГОСТ-криптография применяется в контекстах, заданных нормативными документами и профилями. При проектировании продуктивного контура следует учитывать применимые требования и утверждённые организационные регламенты.

• Федеральный закон № 63-ФЗ «Об электронной подписи» (правовые основы применения электронной подписи).
• Приказ ФСБ № 795 (перечень допустимых криптографических алгоритмов и требований к их применению).
• Профиль ТК-26 (профилирование сертификатов/алгоритмов/расширений и OID-ограничения для российской PKI-практики).

---

3. Термины, сокращения и обозначения

• ГОСТ — семейство российских криптографических стандартов (подпись, хеширование, симметричное шифрование, протоколы обмена).
• OpenPGP — формат и протокол криптографических сообщений (подпись/шифрование), реализуемый утилитой gpg.
• X.509 — формат сертификатов открытых ключей; используется в PKI.
• CMS — Cryptographic Message Syntax (подписи/шифрование контейнеров, в т.ч. S/MIME).
• CRL — Certificate Revocation List (список отзыва сертификатов).
• OCSP — протокол проверки статуса сертификата.
• УЦ — удостоверяющий центр.
• СКЗИ — средство криптографической защиты информации (в контексте регуляторных требований).

---

4. Назначение GnuPG с поддержкой ГОСТ

GnuPG (GNU Privacy Guard) представляет собой набор утилит и служб, реализующих криптографические операции и работу с ключевым материалом. В контексте ГОСТ поддержка применяется для расширения возможностей обработки российских алгоритмов на уровнях:

• OpenPGP-контур (утилита gpg): генерация ключей, подпись, проверка, шифрование и обмен ключевым материалом.
• X.509/CMS-контур (утилита gpgsm): работа с сертификатами, проверка/формирование CMS-подписей (S/MIME), валидация.
• Агентский контур (gpg-agent, keyboxd, dirmngr): хранение ключей, доступ к сертификатам, операции со смарт-картами/токенами (при наличии), проверка статусов по CRL/OCSP.

Практическая причина использования «из коробки» состоит в сокращении времени вывода решения на стенд: инженеру требуется возможность быстро проверить подпись, разобрать цепочку сертификатов, воспроизвести поведение клиента и выявить несовместимость. Данные операции необходимы даже в случаях, когда продуктивное подписание должно выполняться сертифицированным криптопровайдером.

---

5. Состав поставки в НАЙС.ОС и проверка готовности

В НАЙС.ОС сборка GnuPG с поддержкой ГОСТ доступна в базовой поставке. Установка дополнительных пакетов для включения ГОСТ-функциональности не требуется. Контроль готовности выполняется путём проверки версий и перечней доступных алгоритмов в текущей среде выполнения.

5.1. Проверка версий компонент

# Версия GnuPG и перечень поддерживаемых алгоритмов (в выводе обычно присутствуют разделы Cipher/Hash/Pubkey)
gpg --version

# Версия компонента X.509/CMS
gpgsm --version

# Версии библиотек и компонент, используемых GnuPG
gpgconf --show-versions

5.2. Контроль наличия ГОСТ-алгоритмов по факту

Перечень доступных алгоритмов зависит от сборки и криптографического бэкенда. Контроль выполняется по фактическому выводу утилит.

# В выводе gpg --version проверьте наличие ГОСТ-алгоритмов в списках:
# - Hash: (ожидаются варианты Streebog 256/512, если включено)
# - Cipher: (возможны варианты ГОСТ 28147-89, если включено)
# - Pubkey: (ожидается поддержка ГОСТ-ЭЦП/обмена, если включено)
gpg --version | sed -n '1,160p'

---

6. Экономический и инженерный эффект применения

Использование GnuPG с ГОСТ-поддержкой в составе НАЙС.ОС применяется как инженерный инструмент по следующим причинам:

• Сокращение затрат на ранней стадии — прототипирование, интеграционные тесты, отладка цепочек сертификатов и подписей выполняются без обязательного приобретения криптопровайдера.
• Ускорение развёртывания — подготовка стенда и запуск тестовых проверок не требуют отдельной установки и лицензирования.
• Повышение воспроизводимости — проверки алгоритмов, OID, расширений сертификатов, CRL/OCSP выполняются в унифицированной среде, что снижает расхождения между окружениями разработчика, CI и тестового контура.
• Формализация диагностики — наличие CLI-инструментов позволяет фиксировать результаты проверок в виде логов, которые пригодны для инженерного анализа и автоматической регрессии.

В продуктивных сценариях, где требуется соблюдение требований закона и регуляторов к СКЗИ, применяется сертифицированный криптопровайдер. Инженерная ценность GnuPG+ГОСТ при этом сохраняется: инструмент используется для предтестов, воспроизведения дефектов и проверки совместимости входных данных.

---

7. Архитектура компонент и потоки данных

Архитектура GnuPG в типовой конфигурации включает:

• gpg — операции OpenPGP (подпись/проверка/шифрование);
• gpgsm — операции X.509/CMS (S/MIME, CMS-контейнеры);
• gpg-agent — агент ключевых операций и PIN-ввода;
• keyboxd — хранение/индексация сертификатов и ключевых метаданных;
• dirmngr — CRL/OCSP и сетевые обращения PKI-уровня (при включённых проверках).

ГОСТ-поддержка прикладного уровня активируется при наличии реализованных примитивов в криптографическом бэкенде и при распознавании OID из семейства 1.2.643.* в сертификатах и контейнерах. Для диагностики применяются режимы подробного вывода и трассировки.

7.1. Режимы диагностики

# Для OpenPGP-операций (пример)
gpg -vv --debug-level advanced --debug-all --list-keys

# Для X.509/CMS-операций (пример)
gpgsm -vv --debug-level advanced --debug-all --list-keys

---

8. OpenPGP: генерация и эксплуатация ГОСТ-ключей (gpg)

Настоящий раздел описывает операции OpenPGP-контура: генерация ключей, экспорт, подпись, проверка, шифрование и расшифрование. На практике наименования кривых и алгоритмов зависят от сборки; в НАЙС.ОС контроль выполняется по фактическому выводу интерактивной генерации ключей и по доступным идентификаторам в gpg --version.

8.1. Генерация ГОСТ-ключа

# Интерактивная генерация ключа.
# В процессе выбора укажите ECC и доступную ГОСТ-кривую (наименование зависит от сборки).
gpg --full-generate-key

При генерации указываются: тип ключа, параметры кривой, срок действия, идентификатор пользователя (UID: имя, e-mail), параметры защиты секретного ключа (пароль). Для автоматизации допускается применение пакетных режимов (batch) при наличии утверждённого профиля.

8.2. Просмотр ключей и параметров

# Список ключей
gpg --list-keys

# Детальный вывод (включая отпечаток, keygrip)
gpg --list-keys --with-colons

# Просмотр параметров конкретного ключа
gpg --fingerprint KEYID_OR_EMAIL

8.3. Экспорт ключей

# Экспорт публичного ключа (ASCII armored)
gpg --armor --export KEYID_OR_EMAIL > publickey.asc

# Экспорт публичного ключа (binary)
gpg --export KEYID_OR_EMAIL > publickey.gpg

# Экспорт секретного ключа (только для резервного хранения в защищённом контуре)
gpg --armor --export-secret-keys KEYID_OR_EMAIL > secretkey.asc

8.4. Подпись и проверка

# Подпись файла (создание подписи рядом, тип зависит от режима)
gpg --detach-sign --armor artifact.tar.gz

# Проверка подписи
gpg --verify artifact.tar.gz.asc artifact.tar.gz

# Просмотр сведений о подписи (без импорта ключей)
gpg --status-fd 1 --verify artifact.tar.gz.asc artifact.tar.gz

При применении ГОСТ-хеширования идентификатор алгоритма задаётся параметром --digest-algo (если доступно в сборке). Практический контроль выполняется по выводу gpg --status-fd, где фиксируются используемые алгоритмы.

# Пример принудительного выбора хеш-алгоритма (если доступно)
gpg --digest-algo stribog512 --detach-sign --armor artifact.tar.gz

8.5. Шифрование и расшифрование

# Шифрование на получателя (публичный ключ получателя должен быть в keyring)
gpg --encrypt --recipient user@example.org data.txt

# Расшифрование
gpg --decrypt data.txt.gpg > data.txt

Для выбора симметричного алгоритма в OpenPGP допускается применение --cipher-algo при наличии соответствующего алгоритма в сборке. В инженерной практике следует фиксировать фактический алгоритм по статусным строкам и логам.

# Пример выбора симметричного алгоритма (если доступно)
gpg --cipher-algo GOST28147 --encrypt --recipient user@example.org data.txt

---

9. X.509/CMS: применение ГОСТ-сертификатов и CMS-подписей (gpgsm)

Раздел описывает операции с сертификатами X.509 и CMS-контейнерами. Основные операции: импорт сертификатов, просмотр, проверка цепочек, формирование и проверка CMS-подписей, обработка CRL/OCSP при необходимости.

9.1. Импорт сертификатов

# Импорт DER/PEM сертификата в хранилище gpgsm
gpgsm --import cert.der

# Просмотр списка сертификатов
gpgsm --list-keys

# Детальная информация о сертификате
gpgsm --list-keys --with-colons | sed -n '1,200p'

9.2. Разбор сертификата и проверка OID

# Печать сертификата в читаемом виде (ASN.1 поля, расширения)
gpgsm --dump-cert cert.der | sed -n '1,260p'

Для ГОСТ-сертификатов характерно наличие OID семейства 1.2.643.*. Типовые OID (встречаются в реальных цепочках) относятся к алгоритмам подписи и хеширования. Фактическое значение всегда фиксируется по полю Signature Algorithm и по параметрам SubjectPublicKeyInfo.

9.3. Формирование CMS-подписи

# Формирование откреплённой CMS-подписи (S/MIME/CMS)
# Примечание: требуется наличие соответствующего сертификата и связанного ключевого материала в доступном для gpgsm контуре.
gpgsm --detach-sign --output document.p7s document.pdf

9.4. Проверка CMS-подписи

# Проверка откреплённой подписи (при наличии исходного контента)
gpgsm --verify document.p7s document.pdf

# Диагностика проверки (детальный отладочный вывод)
gpgsm -vv --debug-all --verify document.p7s document.pdf

---

10. Проверка цепочки доверия, CRL и OCSP

В инфраструктуре X.509 проверка подписи дополняется проверкой цепочки доверия и статуса сертификатов. В составе GnuPG эти функции реализуются через компонент dirmngr и настройки политики проверки.

10.1. Проверка состояния dirmngr

# Статус сервисов GnuPG (в зависимости от конфигурации может работать как пользовательские процессы)
gpgconf --list-dirs
gpgconf --reload all

# Просмотр активных процессов
ps aux | egrep 'gpg-agent|dirmngr|keyboxd' | grep -v egrep || true

10.2. Базовая модель доверия

Модель доверия и размещение доверенных корневых сертификатов определяется политикой организации и задачей стенда. Для инженерного тестирования допускается раздельная конфигурация:

• контур «разбор структуры/криптопроверка» (без утверждения доверия);
• контур «полная валидация PKI» (с доверенными корнями, CRL/OCSP, политиками).

---

11. Автоматизация и применение в CI/CD

В инженерных процессах GnuPG применяется как CLI-инструмент для проверок артефактов. Требование: команды должны быть детерминированы, результаты — машиночитаемы, журналы — пригодны для аудита.

11.1. Машиночитаемая проверка подписи

# Пример проверки с выводом статусных строк
# В CI обрабатываются строки вида [GNUPG:] GOODSIG, VALIDSIG, BADSIG и т.п.
gpg --batch --status-fd 1 --verify artifact.tar.gz.asc artifact.tar.gz

11.2. Fail-fast режим

set -euo pipefail

gpg --batch --status-fd 1 --verify artifact.tar.gz.asc artifact.tar.gz \
  | tee verify.log \
  | grep -E '^\[GNUPG:\] (GOODSIG|VALIDSIG)\b' >/dev/null

---

12. Типовые неисправности и методика устранения

12.1. Ошибка «unsupported algorithm 1.2.643…»

Признак: входные данные (сертификат/подпись) содержат OID ГОСТ-алгоритма, который не поддерживается текущим криптографическим стеком. Действия:

• зафиксировать версию: gpgconf --show-versions;
• зафиксировать OID: gpgsm --dump-cert или отладочный вывод проверки;
• проверить перечни алгоритмов в gpg --version;
• проверить, что используется целевая сборка НАЙС.ОС с включённой ГОСТ-поддержкой.

12.2. Проверка подписи проходит, но доверие цепочке отсутствует

Признак: криптопроверка корректна, но PKI-валидация не утверждает доверие (нет доверенного корня, отсутствуют CRL/OCSP, несоответствие политик). Действия:

• разделить режимы тестирования: криптопроверка и PKI-проверка;
• добавить доверенные корни по утверждённой процедуре;
• настроить доступ к CRL/OCSP и правила их применения;
• проверить расширения KeyUsage/ExtendedKeyUsage и политики сертификатов.

12.3. Требуется детальная трассировка выполнения

# OpenPGP (пример)
gpg -vv --debug-all --status-fd 1 --verify artifact.sig artifact.bin

# X.509/CMS (пример)
gpgsm -vv --debug-all --verify document.p7s document.pdf

---

13. Граница применения: тестирование против юридически значимых операций

В инженерной практике целесообразно разделять:

• контур разработки/тестирования — проверки, интеграция, диагностика, стенды, CI/CD, регрессионные тесты;
• контур юридически значимых операций — формирование подписи и шифрование в режимах, где требуется сертифицированное СКЗИ, утверждённые регламенты, контроль ключей и аудит.

GnuPG с ГОСТ-поддержкой в НАЙС.ОС применяется для ускорения инженерных циклов и снижения затрат на интеграцию, при этом в целевых регулируемых процессах используются сертифицированные криптопровайдеры и утверждённая инфраструктура.

---

Приложение А (справочное). Минимальный контрольный список инженера

# 1) Версии и состав
gpg --version
gpgsm --version
gpgconf --show-versions

# 2) Проверка ключей/сертификатов
gpg --list-keys
gpgsm --list-keys

# 3) Проверка OpenPGP подписи
gpg --batch --status-fd 1 --verify artifact.sig artifact.bin

# 4) Проверка CMS подписи (S/MIME)
gpgsm -vv --debug-all --verify document.p7s document.pdf

Для отчёта по диагностике дополнительно фиксируются: хеши входных файлов, отпечатки сертификатов, OID алгоритмов и полные отладочные логи.