|
Приветствую! Провел тестирование по намеченному плану. Тестировал только корректность вычисления хэшей, весь прочий функционал не трогал. Считал хэши от следующих файлов: 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 пишет: |
Attachment:
M.zip
Description: Zip archive
md_gost12_512(M1)= 1b54d01a4af5b9d5cc3d86d68d285462b19abc2475222f35c085122be4ba1ffa00ad30f8767b3a82384c6574f024c311e2a481332b08ef7f41797891c1646f48 md_gost12_512(M2)= 1e88e62226bfca6f9994f1f2d51569e0daf8475a3b0fe61a5300eee46d961376035fe83549ada2b8620fcd7c496ce5b33f0cb9dddc2b6460143b03dabac9fb28 md_gost12_512(M3)= 8e945da209aa869f0455928529bcae4679e9873ab707b55315f56ceb98bef0a7362f715528356ee83cda5f2aac4c6ad2ba3a715c1bcd81cb8e9f90bf4c1c1a8a md_gost12_512(M4)= b0fd29ac1b0df441769ff3fdb8dc564df67721d6ac06fb28ceffb7bbaa7948c6c014ac999235b58cb26fb60fb112a145d7b4ade9ae566bf2611402c552d20db7 md_gost12_512(M5)= 363b449ec81ae40b3a407b125c3b1c2b768b50496bcb5f690b89e9007b06e4084182ed45d4072a67fec9d3421dab013da2aabc1d6528e8e775aec7b3457ac675 md_gost12_512(M6)= 8781dfc81d2db6a41d1857f3230b3ffe2bda574273ea1947189aaa5468470df1c4b374b1a2b56e59d11d213fea57e3514543b0ced9b20e553ae66425ec909cfd md_gost12_512(M7)= 03e12ae816c7f794929b7550781d22efc7bc724fd70e295f3123d157c4d577fdc325943ef2b999cc43205dc323fa930bddc60d44663d76844b779fd36aa89de3 md_gost12_256(M1)= 9d151eefd8590b89daa6ba6cb74af9275dd051026bb149a452fd84e5e57b5500 md_gost12_256(M2)= 9dd2fe4e90409e5da87f53976d7405b0c0cac628fc669a741d50063c557e8f50 md_gost12_256(M3)= 3f539a213e97c802cc229d474c6aa32a825a360b2a933a949fd925208d9ce1bb md_gost12_256(M4)= df1fda9ce83191390537358031db2ecaa6aa54cd0eda241dc107105e13636b95 md_gost12_256(M5)= f0a557f6a04a90ab1811c1b6e9b078e4163b74037c6cf59f52444a37f48e11d8 md_gost12_256(M6)= 2f4f651fe88fea46ec6f2223728d8dff3968893558ef00a310c23e7d1923ba0c md_gost12_256(M7)= 633b567983d60243837715e56cc52443ffff9824170ad60b613b2dd6fabf2f40
1b54d01a4af5b9d5cc3d86d68d285462b19abc2475222f35c085122be4ba1ffa00ad30f8767b3a82384c6574f024c311e2a481332b08ef7f41797891c1646f48 M1 1e88e62226bfca6f9994f1f2d51569e0daf8475a3b0fe61a5300eee46d961376035fe83549ada2b8620fcd7c496ce5b33f0cb9dddc2b6460143b03dabac9fb28 M2 8e945da209aa869f0455928529bcae4679e9873ab707b55315f56ceb98bef0a7362f715528356ee83cda5f2aac4c6ad2ba3a715c1bcd81cb8e9f90bf4c1c1a8a M3 b0fd29ac1b0df441769ff3fdb8dc564df67721d6ac06fb28ceffb7bbaa7948c6c014ac999235b58cb26fb60fb112a145d7b4ade9ae566bf2611402c552d20db7 M4 363b449ec81ae40b3a407b125c3b1c2b768b50496bcb5f690b89e9007b06e4084182ed45d4072a67fec9d3421dab013da2aabc1d6528e8e775aec7b3457ac675 M5 8781dfc81d2db6a41d1857f3230b3ffe2bda574273ea1947189aaa5468470df1c4b374b1a2b56e59d11d213fea57e3514543b0ced9b20e553ae66425ec909cfd M6 03e12ae816c7f794929b7550781d22efc7bc724fd70e295f3123d157c4d577fdc325943ef2b999cc43205dc323fa930bddc60d44663d76844b779fd36aa89de3 M7 9d151eefd8590b89daa6ba6cb74af9275dd051026bb149a452fd84e5e57b5500 M1 9dd2fe4e90409e5da87f53976d7405b0c0cac628fc669a741d50063c557e8f50 M2 3f539a213e97c802cc229d474c6aa32a825a360b2a933a949fd925208d9ce1bb M3 df1fda9ce83191390537358031db2ecaa6aa54cd0eda241dc107105e13636b95 M4 f0a557f6a04a90ab1811c1b6e9b078e4163b74037c6cf59f52444a37f48e11d8 M5 2f4f651fe88fea46ec6f2223728d8dff3968893558ef00a310c23e7d1923ba0c M6 633b567983d60243837715e56cc52443ffff9824170ad60b613b2dd6fabf2f40 M7