<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><span style="font-family: Helvetica; font-size: 12px;" class="">If that’s your quality metric, why hash a long key then instead of just (say) truncating it?</span></blockquote></div><div class=""><div class="">If you truncate you may lose entropy.... Suppose the key</div></div></div></blockquote><div class=""></div><blockquote type="cite" class=""><div class="">consists of the concatenation of two passphrases, each encoded in 32</div><div class="">bytes, and each having 50 bits of entropy, for a total of 64 bytes</div><div class="">with 100 bits of entropy.</div></blockquote>The proof of security in the original Bellare et al paper *explictly assumes a random key*. You're wandering off into the wilderness of "it's secure because I don't see any obvious way to attack it" when you start worrying about how the HMAC primitive should deal with non-random keys.</div><div><br class=""></div><div>Consider AES. It takes a key of a given, fixed length. Full stop. How you get it is up to you.</div><div><br class=""></div><div>The security promise for HMAC includes a dependency on the number of bits of *random* keying material you provide. Appending zeroes to the key to get it up to the input block size doesn't change this value. Truncating or hashing gives you a different security guarantee for these longer keys. And dealing with non-random keys is a completely different issue.</div><div><br class=""></div><div>Why should HMAC even deal with varying-length keys? We already have ways to construct a key of a given length from a longer or shorter input. Why build that into every primitive that takes a key?</div><div><br class=""></div><div>My suggestion is that HMAC should be like AES: Defined for a random key whose length equal to the input block size of the hash function on which it's based. Creating such a key is a problem for the user of the primitive. (It may be worth remarking that appending zeroes to a short random key is "good enough" - though you won't find any mention of that in the AES standard either.)</div><div><br class=""></div><div><div> -- Jerry</div><div class=""><br class=""></div></div></body></html>