[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openssl-gost] gostsums



Привет!

14.08.2017 11:59, Dmitry Belyavsky пишет:

> Вопрос к знатокам.
>
> beldmit@manul$ OPENSSL_CONF=engine.conf openssl dgst -md_gost94
> README.gost md_gost94(README.gost)=
> 96e9a38cc52428542044c88d5d427a002f37ac1d5e338185184b7722922b43e2
> beldmit@manul$ bin/gostsum README.gost
> e2432b9222774b188581335e1dac372f007a425d8dc84420542824c58ca3e996
> README.gost
>
> beldmit@manul$ bin/gost12sum README.gost
> be9b6531c5168c26c00566ddee968f41b53b554e0b24953873dabad06a94cc2d
> README.gost beldmit@manul$ OPENSSL_CONF=engine.conf openssl dgst
> -md_gost12_256 README.gost
> md_gost12_256(README.gost)=
> 2dcc946ad0bada733895240b4e553bb5418f96eedd6605c0268c16c531659bbe
>
> Является ли наблюдаемое поведение хорошим, правильным и эталонным? В
> смысле порядка байт.

Является. Потому что какой-то нехороший человек в стандарте GOST
28147-89
написал что байты интерпретируются как Little Endian число.
Вот GOSTSUM и показывает хэш-сумму в виде 16-ричного числа.
А openssl dgst показывает шестнадцатиричный дамп буфера.

Коллбека, который бы позволял управлять визуализацией буфера у openssl
нет.

У SHA* буфер интерпретируется как big-endian и там этой проблемы нет.


Тогда, наверное, это имеет смысл
а) документировать
б) добавить ключ для совместимости с openssl.

Игус?

Если сейчас подать на вход openssl текст из контрольного примера к ГОСТу, то мы увидим хэш-вектор, в котором байты идут в порядке, обратном к тому, как они записаны в контрольном примере.
Я не смог прийти сам с собой к единому мнению :) правильно это или нет.
С одной стороны, в ГОСТе написано, что хэш - это двоичный вектор, у которого есть левая сторона и правая сторона, отсюда можно сделать вывод, что выводиться хэш-вектор должен ровно так, как он записывается в контрольных примерах к ГОСТу: левые знаки слева, правые справа.
С другой стороны, если мы посмотрим, как записываются в контрольных примерах хэшируемые сообщения, и сравним их с 16-ричным дампом соответствующих файлов, то увидим, что слева стоит последний байт файла, а  справа - первый, то есть хэшируемое сообщение записано "перевернутым" по отношению к тому, как оно выводится всеми разумными средствами визуализации. И дабы быть последовательным, следует и хэш-вектор визуализировать "перевернутым" по отношению к записи контрольного примера.

Если принять первую точку зрения, то openssl выводит хэш неправильно, а если вторую - то правильно.
Дегтяревская реализация имеет ключик, позволяющий менять порядок байт в выводе, но по умолчанию используется тот же порядок, что и в openssl. Поскольку Дегтяревская реализация долгое время считалась, а может и доселе считается эталонной, можно приять мужественное решение, что байты нужно выводить ровно в том порядке, в котором их выводит openssl.
gostsum12 из ветки openssl_1_0_2 origin/openssl_1_0_2 (в мастере его нет) их сейчас выводит в том же самом порядке.
gostsum выводит их в обратном порядке (то есть отличном от openssl), поскольку актуальность ГОСТа 94-го года весьма сомнительна, я согласен с идеей старый gostsum из состава энжина исключить.

gost12sum из мастера и из ветки 1.0.2 выводят разные векторы, и оба неправильные.


С уважением,
Игорь Устинов,
Зам.ген.директора
ООО "Криптоком