Приветствую!
Провел тестирование по намеченному плану. Тестировал только корректность
вычисления хэшей, весь прочий функционал не трогал. Считал хэши от следующих
файлов:
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. Там их два:
для сообщения из одного неполного блока и для сообщения из двух блоков, из
которых второй неполный.
Возможно, имеет смысл дополнительно проверить
- сообщение нулевой длины;
- сообщение из одного полного блока;
- сообщение из нескольких полных блоков.
Не знаю, стоит ли делать проверку на очень длинных сообщениях. И что считать
таковыми.
Отдельный вопрос, что использовать в качестве эталона.
С уважением,
Игорь Устинов,
Зам.ген.директора
ООО "Криптоком