GOST R 34.11-2012 hash function works from the end, is this convenient in practice?

Question

RFC 6986

Step 2.
       2.1.  Check the condition |M| < 512
            If it is true, then go to Step 3.
            Else, perform the following calculations:
      2.2.  Calculate the subvector m belonging to V_512 of the message
            M:
            M = M'||m
            Then perform the following calculations:

So, this hash function process message from the end. Is this convinient in practice, when user wants to hash some big data, for example few gigabytes file, or when low CPU/RAM device wants to hash stream of data on the fly? The code have to keep entire message in buffer, and start hashing only when it receives full message.

I understand, that this approach is more secure and eliminate length extension attack, but it is very unpractical.

Answer 1

Actually, GOST R 34.11-2012 hash function doesn't work from the end. It defines M as a binary vector to be hashed. The binary number is usually printed with the least significant bit printed last. When they say M = M'||m, it means that m is a binary sub-vector containing 512 least significant bits of M. And since GOST standard uses big endian everywhere, it actually means the first 64 bytes of the message.

You can clear this up by looking at the source code of a reference implementation, or any other implementation - none of them process the messages from the end.

Answer 2

I understand, that this approach is more secure and eliminate length extension attack

Actually, just be processing the blocks backwards doesn't actually eliminate any attacks. Instead of 'length extension' attacks, we have 'prepend attacks' (where we add the extra blocks to the beginning rather than the end), which yield the same vulnerability.

Now, this 'prepend attack' does not appear to apply to the GOST hash function, but that's because they perform some final block processing involving g_0 (which is distinct from their hash compression function g_N in that they don't xor in the bit counter). However, this defense has nothing to do with the order of processing blocks.

but it is very unpractical.

Depends on their use case; if they always have the message in front of them in memory, it would appear to work just fine.

However, they don't appear to gain anything from making the hash function not computable online (which is the term for the property you're asking about); I have no idea why they did so...