<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="">I went back to the original paper by Bellare, Canetti, and Krawczyk. There, the function is defined as HMAC_k(x) = F(kbar XOR opad, F(kbar XOR ipad, x)) "where kbar is the completion by adding 0’s of k to a full b-bit block-size of the iterated hash function...." (Yes, that's the exact original language.)<div class=""><br class=""></div><div class="">So the original paper didn't even consider the case of a key longer than the input block size. I suspect the way they made their security statement doesn't work for longer keys - which doesn't mean that the construction isn't secure, but the actual security statement is going to be a bit different. Then again ... maybe doing this is *not* secure. (The proof of security of HMAC is based on treating it as a special case of a more general NMAC construction, so it would take some careful study to understand exactly what's being claimed and how it might be affected by a long key.)</div><div class=""><br class=""></div><div class="">It's actually rather disturbing that the standards allowed for a case that the reference document they were relying on for a proof of security didn't cover it.</div><div class=""><br class=""></div><div class=""><div class=""> -- Jerry</div></div><div class=""><br class=""></div><div class=""><div class="page" title="Page 14">
<div class="layoutArea">
<div class="column"><p class=""><span style="font-family: CMR10; font-size: 11pt;" class=""> </span></p>
</div>
</div>
</div></div></body></html>