Errors in FIPS 198 (HMAC)

[Greg Rose]

Dear Jim,

I wasn't sure who to email this comment to, but have met you a couple of 
times, so you're it. I trust you'll forward it as required. (To readers of 
the Cryptography mailing list: please consider Mr Foti if following up.)

In the new FIPS 198 specifying HMAC, there is a typographical error in 
Appendix B which talks about truncating the output HMAC value. In the third 
paragraph it refers to "the block size, b". However, the hash function has 
two block sizes, an input block size "B" and an output block size "L", and 
the output of HMAC (before truncation) is of length "L", not "b" or "B". A 
naive reading of the appendix would have us use a minimum of 256 bits to 
truncate a 160-bit output (referring to SHA-1)! The text in the main body 
correctly uses "L" in this context.

Also, the reference in Appendix A for SHA-1 is to RFC 2104, which I think 
is a bit strange given that there is a perfectly good FIPS (180-1) 
specifying SHA-1. In fact RFC2104 does not "specify" SHA-1 at all, itself 
referring to FIPS-180-1. The only example code in RFC2104 is for MD5.

Lastly, FIPS-180-1 specifies that the output of SHA-1 is 5 32-bit words, 
and explicitly does *not* specify an ordering to the bytes of the output 
words, although common usage is that they should be treated as 
most-significant-byte-first as is done to create words from the input 
bytes. I believe that FIPS-198 should specify a word-to-byte-order, 
otherwise it is impossible to unambiguously truncate the 160-bit output to 
a size that is not a multiple of 32 bits. (Note: I actually consider this a 
deficiency in FIPS-180-1, but I assume that it would be preferable to add 
detail to a new FIPS than to update an old one.)

regards,
Greg.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com