Say I want to perform a hash length extension attack. All the tools I have used use \x00 and \x80 to pad hashes (hlextend and hashpump). But is it necessary to use these bytes? Based on my understanding of padding (and this question: Computing the padding of MD5), it seems that I can use any byte I want. If so, how would I compute the new hash? Would it be the same with using some arbitrary character, like "5", as padding as if I had used null bytes?
1 Answer
But is it necessary to use these bytes?
Yes, it is, at least for most messages that you'll see in practice. MD5 works by taking the message, and applying a fixed padding to it. This fixed padding involves, for messages which are a number of bytes (as opposed to, say, a message of 119 bits) an 0x80 byte, and for not huge messages, 0x00 bytes (in the length field if nowhere else). Then, it runs an iterated compression function over the padded message, and the end result is the MD5 hash.
What the length extension attack does is artificially appends that exact padding pattern to the message; so when the MD5 processes that message, it performs the exact same operation, and so comes up with an intermediate state that is exactly what the MD5 hash output is (which we know). After that, we can append anything else we want (and we can predict how MD5 will handle that, because we now know the MD5 state).
For this to work, we have to do precisely the same padding to the message that MD5 does; because it uses an 0x80 and some 0x00 bytes (for any reasonable message), you do too.
-
$\begingroup$ If I'm not mistaken the length extension attacks on SHA-1 and SHA-2 are identical (apart from the obvious difference in block size), and SHA-3 is not vulnerable against length extension attacks, right? Can we make this question and answer more generic? $\endgroup$– Maarten Bodewes ♦Apr 11, 2016 at 16:02
-
1$\begingroup$ @MaartenBodewes: actually, there are 6 hashes in the SHA-2 family, the length attacks on SHA-256 and SHA-512 (and SHA-1) is identical (except for the differences in the padding); SHA-224 is a bit more tricky (you have to reconstruct the missing 32 bits; doable if you can make a hash query of an extended message); SHA-384, SHA-512/256 SHA-512/224 is essentially invulnerable. $\endgroup$– ponchoApr 11, 2016 at 16:06
-
$\begingroup$ Good point about the reduced output versions of the hashes yes. Having to brute force 32 bits may require some kind of distinguisher I suppose to see if you guessed right. Can't remember a statement from the NIST specs that said that SHA-512/256 is invulnerable to length extension attacks. Fortunate side effect I suppose. $\endgroup$– Maarten Bodewes ♦Apr 11, 2016 at 16:11