ГОСТ Р 34.10-2012/256 — электронная подпись¶
Источник описания и статус реализации
Алгоритм, профиль стандарта и программная поддержка — три разных уровня. RFC Editor публикует многие описания ГОСТ как Informational / Independent Submission, а не как консенсусный стандарт IETF. Наличие RFC не свидетельствует о сертификации СКЗИ и не доказывает поддержку алгоритма каждым приложением НАЙС.ОС. Проверяйте установленную версию и подтверждённые испытания.
Назначение и параметры¶
| Характеристика | Значение |
|---|---|
| Класс | Электронная цифровая подпись на эллиптических кривых |
| Размер блока / результата / профиль | 256-битный профиль параметров |
| Ключевой материал | Закрытый/открытый ключ |
| Основной источник | RFC 7091 |
Как устроен алгоритм и что он гарантирует¶
Алгоритм формирует подпись с помощью закрытого ключа на эллиптической кривой и проверяет её открытым ключом. Входом служит хэш сообщения, как правило, Стрибог-256 в соответствующем стандартизованном профиле. Фактические байты подписываемых данных, выбор доменных параметров, форматы r/s и порядок представления подписи существенно влияют на совместимость.
ГОСТ Р 34.10 не шифрует сообщение: электронная подпись доказывает владение закрытым ключом при условии корректной проверки доверия к открытому ключу. В сценариях X.509 дополнительно нужны цепочка УЦ, назначение ключа, срок действия и статус отзыва.
Не используйте тестовые наборы кривых в эксплуатации. Открытые OID и paramset должны соответствовать RFC 7836, RFC 9215 и требованиям второй стороны. Нельзя считать идентичными сырую подпись, DER-объект и CMS SignedData.
Реализация в НАЙС.ОС: что подтверждено и что проверять¶
- OpenSSL:
openssl genpkey -algorithm gost2012_256 -pkeyopt paramset:TCA -out KEY— пример для поддерживающего этот paramset engine; фактический набор проверить локально. - Подпись файла и проверка: разделы OpenSSL и CMS; не копируйте реальные закрытые ключи в лабораторию.
- DNSSEC: профиль подписей определяет RFC 9558; нельзя напрямую использовать форму подписи OpenSSL без согласования кодирования.
Проверка и критерии приёмки¶
Перед эксплуатацией получите перечень реальных возможностей целевого пакета, а не доверяйте абстрактной таблице криптографии. Положительный тест должен соответствовать выбранному профилю, формату ключей, параметрам и протоколу; отрицательный тест должен демонстрировать отказ при неверном ключе, повреждённых входных данных или неверном теге (если соответствующая защита предусмотрена). Для сетевых профилей отдельно проверьте отказ аутентификации, границы ключевой ротации и предотвращение обхода туннеля.
Эксплуатация и совместимость¶
- Матрица статусов алгоритмов: стандарт, имя системной реализации, подтверждённый тест.
- Использование ГОСТ в ядре Linux, OpenSSL, IKEv2/strongSwan, шифрование дисков.
- OID и параметры, форматы ключей и подписи, векторы испытаний.
- Правила безопасности и полный каталог RFC.
Связь с документами и форматами CMS¶
SignedData и криптографическая подпись · Доверие к сертификату. Для сетевого IKEv2 и ядра правила применения задаются отдельно.