Как стать автором
Обновить

Об open-source реализациях хэш-функции ГОСТ Р 34.11-2012 и их влиянии на электронную подпись ГОСТ Р 34.10-2012

Время на прочтение6 мин
Количество просмотров23K
Всего голосов 22: ↑17 и ↓5+12
Комментарии19

Комментарии 19

Если я правильно помню, то ГОСТ Р 34.11-2012 ещё, к огромному сожалению, не определяет порядок байт, т.е. спецификация дана в терминах 512-битных чисел и не фиксируется как они должны преобразовываться в байты. Конечно, традиционно в криптографии используется big-endian порядок, но определённость здесь бы не помешала…

Можете ли вы дать тестовые вектора которым желательно следовать проверяя реализации? Мне бы очень пригодилось для вот этого проекта.
Примеры на тестовых векторах есть в самом ГОСТ, например здесь docs.cntd.ru/document/gost-r-34-11-2012 смотреть Приложение А.
Эти вектора я уже использовал, но, если я правильно понимаю, они не покрывают ошибку рассматриваемую в статье и могут интерпретироваться с обоими порядками байтов.

Это же ГОСТ Р 34.11-2012, а не ГОСТ Р 34.11-94. Все в ГОСТ.

Похоже, ссылка «Знаменитая реализация Дегтярева» в статье неверная — она указывает на https://github.com/be1ay/MyHash_Stribog (причём там как раз лежит код с ошибкой), однако, скорее всего, имелся в виду репозиторий https://github.com/adegtyarev/streebog.


Как ни удивительно, похоже, в данном случае программисты не смогли правильно реализовать вроде бы простейшую операцию — «длинное» сложение: в некоторых случаях неправильно обрабатывается перенос в старшую часть числа.


В реализации Дегтярева проблема устранена в декабре 2017 года, а позднее код слегка оптимизирован.


В gost-engine для OpenSSL проблема исправлена в марте 2018 года (исправление совпадает с первым вариантом патча для реализации Дегтярева).


В LibreSSL ошибка пока на месте, в libgcrypt эта ошибка тоже присутствует (у этих проектов соответствующий кусок кода совпадает, и существенно отличается от реализации Дегтярева).

Спасибо за замечания и существенные дополнения.


Как ни удивительно, похоже, в данном случае программисты не смогли правильно реализовать вроде бы простейшую операцию — «длинное» сложение: в некоторых случаях неправильно обрабатывается перенос в старшую часть числа.

Мы тоже пришли к такому выводу. И сейчас тестируем правки. Спасибо.

НЛО прилетело и опубликовало эту надпись здесь

Не понял. Это одно из стилистических представлений бога Стрибог.

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

Перевод мне не нравится. Я выразил свою точку зрения и не более того.

Приятно слышать, спасибо. Мы тоже проверивели Stribog еще и на Ruby . Там тоже все хорошо, только учитывать порядок байт не забывать.

Спасибо за статью, но самое главное в практическом смысле это не статья на хабре, а багрепорты и/или пуллреквесты

Спасибо. Но я не согласен с тем, что эта не статья на хабр. А как же люди узнают, что есть ошибки где-то и чем можно воспользоваться, чтобы их избежать? Или как надо тестировать и т.д. Если продукт не выложен для всеобщего доступа, не входит в состав официальных дистрибутивов, особенно российских, тогда да, можно обойтись багрепортами и/или пуллреквестами. Здесь же другая ситуация!
За доброе слово еще раз спасибо.

Пришло сообщение от lumag :


Спасибо, исправлено.
Честно говоря случайно наткнулся на эту статью и совершенно не ожидал что «Знаменитая реализация Дегтярева» ведет на мою старую репу, за которую мне стало стыдно…
Поэтому решил обновить исходники (взяв свежие исходники Дегтярева и переделав форму на QML), оставил только ГОСТ-овский алгоритм и добавил выбор little-endian, big-endian.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации