Перейти к содержанию

Стрибог-256 — ГОСТ Р 34.11-2012

Источник описания и статус реализации

Алгоритм, профиль стандарта и программная поддержка — три разных уровня. RFC Editor публикует многие описания ГОСТ как Informational / Independent Submission, а не как консенсусный стандарт IETF. Наличие RFC не свидетельствует о сертификации СКЗИ и не доказывает поддержку алгоритма каждым приложением НАЙС.ОС. Проверяйте установленную версию и подтверждённые испытания.

Назначение и параметры

Характеристика Значение
Класс Криптографическая хэш-функция
Размер блока / результата / профиль Выход 256 бит
Ключевой материал Секретный ключ не требуется
Основной источник RFC 6986

Как устроен алгоритм и что он гарантирует

Стрибог-256 преобразует последовательность произвольной длины в отпечаток длиной 256 бит. Алгоритм использует 512-битное внутреннее состояние, последовательное сжатие и учёт длины/суммы блоков; вывод в 256 бит — отдельный нормативный вариант, а не просто сокращение вывода Стрибог-512. Для одних и тех же байтов результат детерминирован.

Хэш пригоден для контрольных сумм при наличии доверенного эталона и как компонент электронной подписи, HMAC, PRF и KDF. Один хэш не доказывает личность отправителя и не защищает данные от подмены одновременно с хэшем. При обмене файлами необходимо сохранять точную последовательность байтов, включая перевод строки и кодировку.

Свойства стойкости зависят от использования по назначению; размер хэша не равен длине шифровального ключа, алгоритм не шифрует и не расшифровывает данные.

Реализация в НАЙС.ОС: что подтверждено и что проверять

  • OpenSSL: openssl dgst -md_gost12_256 FILE при подключённом ГОСТ engine.
  • Linux Crypto API: streebog256; AF_ALG позволяет вызывать его без собственной криптографической реализации.
  • ГОСТ DNSSEC 2012 использует нормативно определённое представление хэша/подписи; см. RFC 9558.

Проверка и критерии приёмки

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

Эксплуатация и совместимость

Связь с документами и форматами CMS

Хэш в CMS SignedData · OID и кодировки. Для сетевого IKEv2 и ядра правила применения задаются отдельно.