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

Step 2.
       2.1.  Check the condition |M| &lt; 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.
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...