Errors in FIPS 198 (HMAC)

[Donald Eastlake 3rd]

RFC 3174 contains code for SHA-1. While I think it is pretty reasonable
that NIST preferentially reference its own documents, there may be
people looking for compilable source or who prefer ASCII documents, so
it is also reasonable to reference an RFC.

Thanks,
Donald

On Fri, 5 Apr 2002, Greg Rose wrote:

> Date: Fri, 05 Apr 2002 11:24:18 +1000
> From: Greg Rose <ggr at qualcomm.com>
> To: foti at nist.gov
> Cc: ggr at qualcomm.com, cryptography at wasabisystems.com
> Subject: Errors in FIPS 198 (HMAC)
>
> 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
>


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