Исправить проверочный пример Г.2

[makavity]

В таблице Г.6 определен тестовый пример генерации одноразового личного ключа:

В таблице Г.2 определен другой личный ключ для этих же значений:

Согласно вычислений, правильный одноразовый ключ определен в таблице Г.6.

[makavity]

Аналогично, результат выработки ЭЦП:
Методика испытаний:

Таблица Г.2:

[mkazl]

@makavity Не совсем понятно, как одноразовый личный ключ может быть "правильным"?

Согласно алгоритму выработку ЭЦП (СТБ 34.101.45, пункт 7.1.3) одноразовый личный ключ на шаге 2 выбирается случайно равновероятно из множества чисел от 1 до q - 1 (в соответствии с требованиями подраздела 5.4). При этом в подразделе 5.4 сказано

Для создания одноразовых личных ключей при выработке ЭЦП может использоваться алгоритм генерации, определенный в 6.3.3

Ключевой слово "может" говорит о необязательности использования алгоритма, определенного в пункте 6.3.3, для генерации одноразового личного ключа. Следовательно, в тестовом примере вполне может использовать одноразовый личный ключ, полученным отличным от алгоритма генерации из пункта 6.3.3 способом.

При этом если использовать входные параметры из таблицы Г.2, то получившееся значение подписи будет соответствовать приведенному в таблице Г.2 (во всяком случае на моей реализации). Таким образом, на мой взгляд, основания для корректировки проверочного примера Г.2 отсутствуют.

Что касается использования другого одноразового личного ключа в методике испытаний, то, вообще говоря, отсутствуют какие-либо нормативные требования, обязывающие при разработке методике использовать тестовые данные из соответствующего стандарта. Насколько я помню, тестовые данные для методик должны быть получены либо с помощью некоторой эталонной реализации, либо двумя независимыми реализациями.

[makavity]

Тогда думаю, следует описать, какой алгоритм использовался для одноразового ключа.

[mkazl]

Тогда думаю, следует описать, какой алгоритм использовался для одноразового ключа.

Насколько я вижу, применялся алгоритм генерации псевдослучайных чисел в режиме счетчика (СТБ 34.101.47-2017, пункт 6.2): используемые в примере Г.2 личный ключ и одноразовый личный ключ соответствуют первым двум строкам Y из таблицы В.2.

Но, честно говоря, мне не совсем понятно, в чем может быть практический смысл в описании этого алгоритма. Разве что стоит задача сэкономить несколько десятков байт памяти, чтобы не задавать ключ константно, а вычислить его по алгоритму...

[makavity]

Суть в том, что передавать в алгоритм дополнительный параметр, в качестве одноразового лично ключа - достаточно бесполезно, потому что это можно сделать внутри алгоритма.
Касательно передачи одноразового личного ключа отдельным параметром - не видел ни одной такой реализации. И подозреваю, что это не лучшая практика.

[mkazl]

Суть в том, что передавать в алгоритм дополнительный параметр, в качестве одноразового лично ключа - достаточно бесполезно, потому что это можно сделать внутри алгоритма.

Я обычно работал с интерфейсами алгоритма выработки ЭЦП, сделанными по аналогии с Bee2, в котором входными параметрами являются генератор и, возможно, его текущее состояние. В таком случае можно передавать внутрь алгоритма "фейковый" генератор, который всегда возвращает нужные константные данные.

Касательно передачи одноразового личного ключа отдельным параметром - не видел ни одной такой реализации. И подозреваю, что это не лучшая практика.

А я видел. Никаким действующим ТНПА это не противоречит в общем случае.

[agievich]

Действительно, в примерах Г.2 и Г.6 для подписи одного и того же сообщения на одном и том же долговременном личном ключе $d$ используются разные одноразовые ключи $k$. Это нормальная практика для подписи Шнорра в целом и для Bign в частности.

Действительно, разные $k$ в примерах Г.2 и Г.6 могут запутать. Поэтому
в Г.6 вместо

В таблицах Г.6, Г.7 представлены примеры генерации одноразового личного ключа.

предлагается писать

В таблицах Г.6, Г.7 представлены примеры генерации одноразового личного ключа с помощью алгоритма, установленного в 6.3.

Что касается "расшифровки" способа генерации $k$ в Г.2, то вряд ли имеет смысл это делать. Ведь $k$ здесь -- это случайный/псевдослучайный ключ, сгенерированный за пределами bign-sign. Сгенерированный способом, не относящимся к алгоритмам Bign.