<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;"><br><div><div>On Feb 2, 2017, at 2:10 PM, Francisco Corella <<a href="mailto:fcorella@pomcor.com">fcorella@pomcor.com</a>> wrote:</div><br><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Please keep in mind that HMAC is also standardized in <a href="http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf" class="">NIST FIPS 198-1</a>.</div><div class="">Let's not introduce unnecessary confusion by putting standards out of</div><div class="">sync. I don't see any reason for changing HMAC. Regarding the</div><div class="">message that started this thread, there is a clear reason for padding</div><div class="">the key with zeros when shorter than the block size rather than</div><div class="">hashing it: hashing has a substantial computational cost. Supposedly</div><div class="">"simplifying the code" is not an argument for introducing an</div><div class="">unnecessary hash.</div></div></div></blockquote><div><br></div><div>If that’s your quality metric, why hash a long key then instead of just (say) truncating it?</div><div><br></div><div>rg</div><div><br></div></div></body></html>