Not quite. HMAC helps to prevent length extensions attacks (if the underlying hash was vulnerable in the first place), and the secret prevents attackers from predicting the hash value (like OP did).
But HMAC doesn't help against ambiguously encoded inputs:
hmac(key, 'aa'+'bb') == hmac(key, 'aab'+'b')
You want a way to unambiguously join the values. Common solutions are:
- prepending the length of each field (in a fixed number of bytes);
- encoding the input as JSON or other structured format;
- padding fields to fixed lengths;
- hashing fields individually, then hashing their concatenation;
> When I saw this, I wondered why it has several inner hashes instead of using the raw string.
The inner hash constrains the alphabet on that portion of the input to the outer hash, thus easily letting you use a separator like "," or "|" without having to deal with the alphabet of the inner input, since it gets run through a hash. That is, for a very simplistic use case of two inputs a & b:
sha256(','.join(
[sha256(a), sha256(b)]
))
If one is familiar with a git tree or commit object, this shouldn't be unfamiliar.
Now … whether that's why there was an inner hash at that point in TFA's code is another question, but I don't think one should dismiss inner hashes altogether.
I could see an attack vector here based on file/directory names or the full path. Different inputs could lead to the same order of enumerated checksums.
I'm not dismissing them, inner hashes returning a hexadecimal string fulfills the "the separator should not be able to show up in the inputs" constraint.
Thanks—that makes sense. I was struggling to come up with an example that would fail but I was just unconsciously assuming the separator wasn’t showing up naturally in the individual parts instead of explicitly considering that as a prerequisite.
But HMAC doesn't help against ambiguously encoded inputs:
You want a way to unambiguously join the values. Common solutions are:- prepending the length of each field (in a fixed number of bytes);
- encoding the input as JSON or other structured format;
- padding fields to fixed lengths;
- hashing fields individually, then hashing their concatenation;
- use TupleHash, designed specifically for this case: https://www.nist.gov/publications/sha-3-derived-functions-cs...