For the scrypt HMAC storage format, why run the input of the hash and the hash itself into the HMAC Generally if the body is hashed, why provide the body and the hash as input into the HMAC.  Instead wouldn't the same security be achieved by hashing the body and providing only the hash as input into the HMAC?

I looked at the documentation here. I also looked at the answer here which provides detailed description of which byte is used for which algorithm.

These two documentations state that when computing the HMAC bytes 0 to 63 are used as input. Also, when computing the SHA-256 HASH bytes 0 to 47 are used as input.

Since any change in bytes 0 to 47 would change bytes 48 to 63.  Why bother providing bytes 0 to 47 as input into the HMAC.  Would the security be the same if the HMAC used bytes 48 to 63 as input?
Since any change in bytes 0 to 47 would change bytes 48 to 63. Why bother providing bytes 0 to 47 as input into the HMAC. Would the security be the same if the HMAC used bytes 48 to 63 as input?


No, because that would be taking the HMAC of a 16-byte, i.e. 128-bit hash, rather than the 48-byte actual value. The HMAC has 256-bit security, while taking the HMAC of the hash would only have 128-bit preimage resistance and 64-bit collision resistance.

Now, whether that could lead to a practical attack, I am not so sure. A collision attack on the hash could be within reach, but I cannot immediately see any benefit to an attacker from it. Still, if you are going to take a 256-bit HMAC, there is no need to reduce the security with an initial hash.