3 ms·
Yeah, a message less than blocksize bytes is padded with 0's, and a message greater than blocksize bytes is hashed to blocksize bytes. It "follows" just as muc
by dakami 11y ago
Yeah, a message less than blocksize bytes is padded with 0's, and a message greater than blocksize bytes is hashed to blocksize bytes. It "follows" just as much as Little MAC, is about as security relevant, and is no less clever (arguably a bit more).
- tptacek 11y agoCan you be a little more specific about the cleverness you're referring to here?
- dakami 11y agoSure! HMAC keys are exactly one block long. But lets say an app wants to have a key that's two blocks long. No big deal, hash that app key and now two is one. Ah, but now let's say the attacker has control of input keys. He can provide both the two block key which HMAC will hash for him, or he can do the work himself and prehash the two into one. Now two different input keys seem to provide the same output (assuming identical messages, of course). Clever, no likely security impact.
- sarciszewski 11y agoBecause of the way HN structures comments, it took me a second to realize this wasn't a reply to my comment. (Or maybe I need glasses.)
- marshray 11y agoMessage, or key? (Hi guys something unrelated finally prompted me to unfreeze my HN account!)
- dakami 11y agoYou're right. HMAC keys, from the internal hash perspective, are always one block long. So if the key coming into HMAC is less than blocksize, it's zero padded to blocksize. And if the key coming into HMAC is length greater than blocksize, it's hashed down to blocksize. Obviously this does create collisions if the key ends with nulls and is less than 64 bytes, or if the attacker can specify keys. None of this likely matters in practice.