As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that.
> You would indeed be better off using SHA256.
Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the case. That being said: upgrading is not hard if it even comes to the point where it would be necessary.
Do you really want to be the guy promoting a message verification library who won't use SHA-2 because of the extra 14 bytes of digest length? You made a design mistake here. Just fix it.
Neils Ferguson, et. al of Cryptography Engineering (p. 95) suggest that truncating a HMAC-SHA-256 to 128 bits should be safe, given current knowledge in the field.
This is code that's mostly going to be used in Python web apps (if at all). I thought about arguing in favor of truncating the hash, but then figured this guy would just say "well, I'm not so sure, so to be on the safe side... [I'll use an inferior hash]"... a better argument is, just eat the extra bytes and stick them on your message.
As it is, the size of that digest is also 14 bytes more and I don't feel happy truncating the hash. The bigger SHA2 versions are even longer. Considering that thing should go into cookies and URLs I did not feel very happy with that.
> You would indeed be better off using SHA256.
Probably. I was indeed under the impression that SHA2 is based on the same building blocks as SHA1 but I assume that is not the case. That being said: upgrading is not hard if it even comes to the point where it would be necessary.