# Why does HOTP use such a complex truncate function?

In the HOTP protocol after calculating a 20 byte hash it is truncated to 4 bytes.

For this first an offset is calculated (low-order 4 bits of the last byte) which determines the four bytes to be selected:

DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P


Why is this more 'secure' than simply always taking the first four bytes of the hash?

-
Looks like over-engineering to me. – fgrieu Nov 2 '12 at 20:48

If any of the input bits to the hash differed originally, at least some of bits in the last four bytes will reflect it, with the expected reduction in collision resistance from $2^{80}$ to $2^{16}$.
 You meant from $2^{80}$ to $2^{16}$. – bob Nov 3 '12 at 21:05 You're right, I forgot the birthday paradox for computing collision resistance of a hash function. I edited the answer. – John Deters Nov 5 '12 at 15:08 The answer(s) given seem plausible enough to accept, they confirmed my suspicions. – Jeff Nov 6 '12 at 13:46 The interesting number is not collision resistance, but "MAC forgery resistance", which is still $2^{31}$ for the truncated bits (the top bit is blanked out to avoid worrying about signed versus unsigned calculations) and about $10^d$ for the final resulting number, $d\leq 8$ being the number of decimal digits. – Paŭlo Ebermann♦ Nov 7 '12 at 21:02