Импортозамещение в I2P: подпись по ГОСТ Р 34.10-2012

[degs]

Красиво. Но дополнительный хаб "Ненормальное программирование" был бы тут не лишним.

[orignal]

Я все таки лучше почитаю стандарт, в которым черным по белому написано «вычислить подвектор m сообщения M=M'||m». И все реализации (возможно кроме вашей) идут в обратном порядке.

[stargrave2]

Ivan_83 всё же прав. Как минимум, это было бы просто не логично: хэш который считается над данными в обратном порядке никому не нужен, так как это бы банально бы не позволило потоково обрабатывать данные. 34.11-2012 есть в https://tools.ietf.org/html/rfc6986.html#section-10 где в примерах показано как его надо высчитывать. Сбивает с толку то, что авторы любят записывать *примеры* в обратном порядке. Все использующиеся в «бою», на практике реализации делают как описал Ivan_83.

[orignal]

КриптоПро, однако, придерживается иного мнения, и вычисляет именно так, как описано в стандарте.
В этом легко убедиться, воспользовавшись их утилитой для файла с примером.

[stargrave2]

Хм, я возможно тогда не так понял Ivan_83. КриптоПро утилитка которую вы показали делает хэши точно так же как вот например (я просто их автор) http://pygost.cypherpunks.ru/ и http://gogost.cypherpunks.ru/. То есть, с моей точки зрения — всё правильно, как и ожидалось. Если у вас всё так же как и у ней — то и у вас всё правильно. Просто ещё и взглянул на ваш C++ код в котором для 256-бит версии Стрибога делается memcpy — я не C программист и подумал что «отрезаются» первые 32 байта от хэша и это становится возвращаемым значением функции. Или я не так понял memcpy или ещё где-то что-то «крутится», но КриптоПро утилита действительно верна.

[saipr]

существующая реализация предполагает хранение и передачу публичных ключей и подписей в формате DER

Это что-то новое для openssl. Кто мешает работать с PEM,!