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

Лаборатория испытаний ГОСТ: воспроизводимость и доказательства

Процедура построения тестового стенда, где успех проверяется по эталонным данным, а отказ — предсказуем.

Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.

Устройство испытательного стенда

Для независимых испытаний создайте отдельную виртуальную машину НАЙС.ОС, не связанную с рабочими ключами. Сохраните сведения об используемом ядре, конфигурации сборки, OpenSSL, cryptsetup, GnuPG/libksba и сертификатах. Для тестов со шлюзами нужна вторая виртуальная машина или тестовое оборудование производителя.

Шаг 1. Фиксируем версии

uname -r
openssl version -a
cryptsetup --version
gpg --version | head -20
rpm -qa | grep -Ei 'openssl|cryptsetup|gnupg|libksba' | sort

Отсутствие некоторых программ — отдельный результат, а не повод подменять испытание другой программой.

Шаг 2. Проверяем уровни криптографии

grep -A12 -E '^name *: (kuznyechik|xts\(kuznyechik\)|cbc\(kuznyechik\))$' /proc/crypto
openssl list -providers -verbose
openssl list -digest-algorithms | grep -Ei 'gost|streebog'

Для встроенной архитектуры ядра проверяйте Kconfig и /proc/crypto, а не наличие внешнего RPM ГОСТ-модулей. /proc/crypto может показывать зарегистрированный шаблон или реализацию после первого обращения к алгоритму, поэтому отсутствие записи до запроса не всегда означает отсутствие возможности в конфигурации.

Шаг 3. Выполняем векторные тесты

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

Шаг 4. Негативные тесты

Для AEAD меняем один байт тега, затем один байт связанного заголовка. Для подписи меняем один байт сообщения, подписи и сертификата. Для LUKS проверяем отказ на неверный пароль и повторное открытие после закрытия; не используем для этого реальные рабочие разделы.

Шаг 5. Проверяем обновление

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

Критерий успеха

PASS означает, что известный вход дал ожидаемый выход. SKIP — тест невозможен из-за отсутствия реализации. FAIL — несоответствие. Не трактуйте SKIP как успешное испытание. Запись PASS на OpenSSL не свидетельствует о работе Linux Crypto API, а PASS на AF_ALG не свидетельствует о поддержке S/MIME.

Манифест испытания

Каждый протокол включает case_id, источник, component, version, input_hash, expected, actual, outcome, limitations, operator, дату и ссылку на обезличенный лог. Такая структура позволит публиковать результаты на docs.niceos.ru без ложных универсальных гарантий совместимости.

Первоисточники и дополнительное чтение

  • RFC 7801 — устройство «Кузнечика», § 5 с официальным примером.
  • RFC 9058 — режим MGM, приложение A с тестовыми векторами.
  • RFC 9215 — ГОСТ-2012 в сертификатах и списках отзыва.