Re: [openssl-gost] gostsums

[Andrey Kulikov <amdeich@gmail.com>]

> Результаты:
> 1) КриптоПро неправильно считает хэши от файла больше 4Гб (приводит длину по модулю 4Гб и считает хэш от начальной части файла приведенной длины).

Интересно, повторяется ли такое с cpverify (
https://www.cryptopro.ru/faq/how-to-checksum )...
Завтра првоерю.

2017-08-16 20:46 GMT+03:00 Igor Ustinov <igus@cryptocom.ru>:
> Приветствую!
>
> Провел тестирование по намеченному плану. Тестировал только корректность
> вычисления хэшей, весь прочий функционал не трогал. Считал хэши от следующих
> файлов:
> M1 - сообщение из контрольного примера 1 к ГОСТу 2012 года
> M2 - сообщение из контрольного примера 2 к ГОСТу 2012 года
> M3 - сообщение нулевой длины
> M4 - сообщение из 64 нулей
> M5 - сообщение из 64 не нулей
> М6 - сообщение из 192 не нулей (М5 повторенное 3 раза)
> М7 - сообщение длины более 4Гб (состоит из сообщения M2, к которому 2^26 раз
> дописано сообщение M5)
>
> Хэши считал следующими программами:
> - утилита Дегтярева
> - gostsum12 из ветки 1.0.2 (как я уже писал ранее, это единственный вариант,
> считающий хэши правильно)
> - OpenSSL 1.0.2 с патчами от КриптоПакета и c ccgost  из ветки openssl_1_0_2
> origin/openssl_1_0_2
> - КриптоПакет 3.0
> - утилита csptest из комплекта CryptoPro CSP 4r3
> csptest запускал, понятно, под виндой, утилиту Дегтярева - под линуксом
> (xubuntu), gostsum12, OpenSSL и КриптоПакет как на линуксе, так и на спарке
> (дабы проверить корректность работы на big-endian архитектуре).
> Считал хэши как 256, так и 512 бит.
> Для csptest, КриптоПакета и OpenSSL дополнительно считал и сравнивал хэши по
> gost94.
>
> Результаты:
> 1) КриптоПро неправильно считает хэши от файла больше 4Гб (приводит длину по
> модулю 4Гб и считает хэш от начальной части файла приведенной длины).
> 2) gostsum12 на спарке при попытке посчитать хэш от файла больше 4Гб выдает
> ошибку
> M7: Value too large for defined data type
> (на линуксе считает без проблем).
> 3) КриптоПакет/OpenSSL и csptest по разному считают хэш 94 года от файла
> нулевой длины, разбираться не вижу смысла.
> 4) В остальном всё везде всегда считается одинаково.
>
> В аттаче:
> M.zip - архив с сообщениями, от которых считались хэши (по понятным причинам
> туда не включено сообщение M7, вместо него включен скрипт make4Gb, которым
> это сообщение формировалось)
> OpenSSL.hashes - значения хэш-векторов от этих файлов в формате вывода
> openssl dgst
> GS12.hashes - значения хэш-векторов от этих файлов в формате вывода утилиты
> gostsum12
>
>
> Дополнительно обнаружено, что OpenSSL ломается на попытке проверить CMS типа
> DigestedData, содержащее данные нулевой длины, выдается ошибка
> Verification failure
> 139943902074520:error:2E06307F:CMS routines:CHECK_CONTENT:no
> content:cms_smime.c:120:
> При этом командой dgst хэш от файла нулевой длины выдается ровно тот, что
> записан внутри CMS, так что проблема именно в разборе CМS, а не в реализации
> алгоритма хэширования.
>
> С уважением,
> Игорь Устинов,
> Зам.ген.директора
> ООО "Криптоком
>
> 08.08.2017 18:19, Igor Ustinov пишет:
>
> 08.08.2017 14:26, Dmitry Belyavsky пишет:
>
> А интересует меня, правильно ли считает хеши gostsum12
>
>
> Вопрос о необходимом объеме тестирования "считалки хэшей" меня несколько
> озадачил. Понятно, что контрольные примеры из ГОСТа - это must.  Там их два:
> для сообщения из одного неполного блока и для сообщения из двух блоков, из
> которых второй неполный.
> Возможно, имеет смысл дополнительно проверить
> - сообщение нулевой длины;
> - сообщение из одного полного блока;
> - сообщение из нескольких полных блоков.
> Не знаю, стоит ли делать проверку на очень длинных сообщениях. И что считать
> таковыми.
> Отдельный вопрос, что использовать в качестве эталона.
>
> С уважением,
> Игорь Устинов,
> Зам.ген.директора
> ООО "Криптоком
>
>
>