Официальные тестовые векторы: что они доказывают и как их применять¶
Учимся проверять реализации «Кузнечика», «Магмы», Стрибога, MGM, VKO и подписи с воспроизводимыми исходными данными.
Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.
Зачем нужны векторы¶
Тест «расшифровали то, что сами зашифровали» полезен, но недостаточен: две зеркально неправильные операции могут дать совпадающий результат. Тестовый вектор позволяет проверить конкретную реализацию по результату, полученному из независимой спецификации.
Открытый вектор «Кузнечика» из RFC 7801, § 5.4–5.5:
Key: 8899aabbccddeeff0011223344556677fedcba98765432100123456789abcdef
Plaintext: 1122334455667700ffeeddccbbaa9988
Ciphertext: 7f679d90bebc24305a468d42b9d4edcd
Это один блок ECB-шифрования, а не XTS и не CMS. Не применяйте ECB для шифрования реальных файлов. Ключ учебный и опубликован в стандарте, он не пригоден для защиты данных.
Пробный запуск через OpenSSL¶
Если ваш OpenSSL Provider поддерживает «Кузнечик» в ECB, можно проверить один блок. Убедитесь, что в реальной системе есть соответствующее имя шифра:
Если команда openssl enc в вашей сборке и провайдере допускает нужный шифр, используйте тестовый ключ и данные:
printf '1122334455667700ffeeddccbbaa9988' | xxd -r -p > /tmp/kuz-block.bin
openssl enc -kuznyechik-ecb -nopad -K \
8899aabbccddeeff0011223344556677fedcba98765432100123456789abcdef \
-in /tmp/kuz-block.bin -out /tmp/kuz-block.enc
xxd -p -c 256 /tmp/kuz-block.enc
Ожидаемый результат — 7f679d90bebc24305a468d42b9d4edcd. Если openssl enc не понимает имя, это ограничение интерфейса/провайдера данной сборки; не подменяйте его проверкой через AES.
Для проверки ядра¶
AF_ALG позволяет обратиться напрямую к Linux Crypto API. Для такого контрольного примера требуется шифрование одного блока без дописывания padding. Но socket API нужно использовать корректно с sendmsg_afalg, recv и отдельными соединениями для операции; пример общего round-trip подробно приведён в руководстве AF_ALG. Тот пример подтверждает взаимную обратимость; для KAT нужно подать именно приведённые выше фиксированные байты и сравнить их с ожидаемым шифртекстом.
Где находятся независимые векторы¶
| Алгоритм/режим | Документ | Раздел |
|---|---|---|
| «Кузнечик» | RFC 7801 | 5.4–5.6 |
| «Магма» | RFC 8891 | 5 (тестовые примеры) |
| Стрибог | RFC 6986 | 10.1–10.2 |
| MGM на «Кузнечике» и «Магме» | RFC 9058 | Приложение A |
| VKO, HMAC и KDF | RFC 7836 | Приложения и соответствующие разделы |
| Подпись ГОСТ-2012 | RFC 7091 | 7 |
Каким должен быть журнал теста¶
Записывайте: RFC, точный раздел вектора, реализацию и версию библиотеки, идентификатор алгоритма, размер входа, hex ожидаемого и фактического выхода, результат и дату. Для проверки реализации дополните положительные примеры негативными: изменение одного бита текста, ключа, тега, nonce или подписанных атрибутов должно приводить к ожидаемому отказу.
Файл assets/data/kuznyechik-rfc7801.json в проекте содержит именно этот публичный KAT. Он не является коллекцией закрытых ключей.
Первоисточники и дополнительное чтение¶
- RFC 7801 — устройство «Кузнечика», § 5 с официальным примером.
- RFC 8891 — «Магма», преобразование и контрольные примеры.
- RFC 6986 — «Стрибог» и контрольные примеры.
- RFC 9058 — режим MGM, приложение A с тестовыми векторами.
- RFC 7836 — HMAC, PRF, KDF, VKO и параметры кривых.
- RFC 7091 — алгоритм электронной подписи ГОСТ Р 34.10-2012.