> hmac-md5 might not be vulnerable, but snmp doesn't use pure hmac-*; in > the case of md5 and sha1 it strips the result back to 12 bytes (for > sha256 it's 24 bytes). I'm not saying that is insecure because of it; I > haven't seen any research on the truncation of HMAC, but when combined > with known problematic hashing algorithms it doesn't increase my > confidence level.
The hash used in an HMAC construction needs much weaker properties than a cryptographic hash (in particular no collision resistance). Basically, that's because there's still a private key involved that isn't known to the attacker. The brokenness of md5 and sha1 isn't strong enough yet to compromise hmac-md5 and hmac-sha1. The rule of thumb is that you need to keep at least half the size of the hash in a truncated HMAC.Since SHA-1 has 160 bits and MD5 128 bits, keeping 12 bytes is fine. This corresponds to "96 bits of security". This isn't all that great by today's standards, but far from completely bonkers.
