[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