Many-sided GOST R 34.11-94

I was preparing somehow tests for the system, one of the modules of which, among other things, calculated the value of the hash function for the downloaded file. The required algorithm was prescribed in the TZ - GOST R 34.11-94. For the standard, I took the value of the hash counted by the third-party utility Rhash .

f86c9ecfb6e63726b35ebc79528d013d52b781e06e29d7eb0c9d1cb256efb7c1

Understanding that the function is calculated by the standard library, I sent a request to clear my conscience, which corresponds to loading the file into the module. But the fate of man is full of surprises. And you just have to relax, as you see something like this:
')
964ba8755ca782ec3c5e0f98c93347f9b96d9f39cf5c7fdef43a23273fe8868a

Who is not right - the developer of the module or utility?

It turned out neither one nor the other.

The fact is that GOST R 34.11-94 implies the use of parameters - the so-called replacement nodes and the starting hash vector. But does not regulate specific values. Nevertheless, in the annex to GOST there are examples of these values ​​and recommendations:

Use only in test cases for this standard.

After studying the subject area, it turned out that there are two RFCs. RFC 4357 , which uses the parameters created by CryptoPro, and RFC 5831 with the same values ​​from GOST. Rhash by default considers a hash as per RFC 5831. The use of CryptoPro parameters must explicitly specify:

rhash --gost-cryptopro < >

It would seem that the problem is solved. But to make it even more interesting, the standard does not define the format of the hash output. And so the question arises with the order of bytes .



For the uninitiated, there are two basic ways to present data. From high byte to low (Big-endian) and vice versa (Little-endian).

Consider an example. For clarity, highlighted bytes.

Big-endian byte order:

rhash --gost-cryptopro --gost-reverse < >
8a86e83f27233af4de7f5ccf399f6db9f94733c9980f5e3cec82a75c75a84b 96

Little-endian order:

rhash --gost-cryptopro < >
96 4ba8755ca782ec3c5e0f98c93347f9b96d9f39cf5c7fdef43a23273fe8868a

Thus, there is no contradiction - all of the above values, as well as

rhash --gost --gost-reverse < >
c1b7ef56b21c9d0cebd7296ee081b7523d018d5279bc5eb32637e6b6cf9e6cf8

correspond to GOST R 34.11-94.

References:
Wikipedia
Detailed description