[Cryptography] Why is a short HMAC key zero-padded instead of hashed?

Francisco Corella fcorella at pomcor.com
Thu Feb 2 17:10:13 EST 2017



> On Feb 1, 2017, at 6:21 PM, Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:
> 
> I'll ask on cfrg and dispose of that accordingly. I'm not
> sure the suggested fix is the right thing, nor what is done
> in deployed code.
> 
> Thanks for bringing that up
> 
> S.

Stephen,

Please keep in mind that HMAC is also standardized in NIST FIPS 198-1 <http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf>.
Let's not introduce unnecessary confusion by putting standards out of
sync.  I don't see any reason for changing HMAC.  Regarding the
message that started this thread, there is a clear reason for padding
the key with zeros when shorter than the block size rather than
hashing it: hashing has a substantial computational cost.  Supposedly
"simplifying the code" is not an argument for introducing an
unnecessary hash.  Regarding the supposed vulnerability caused by
hashing a key longer than the block size, the erratum as written up
does not make sense to me.

Francisco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170202/aa40bc41/attachment.html>


More information about the cryptography mailing list