Subject: [Cfrg] Non Zero Constants in HMAC-SHAx

From: "Manav Bhatia" <[email-masked]>
Date: Fri, 13 Apr 2007 22:17:22 +0530

Hi,

I am working on an IETF draft that proposes to provide HMAC-SHA
authentication support for the routing protocols like IS-IS and OSPF.

Link to the OSPF draft:

http://www.ietf.org/internet-drafts/draft-ietf-ospf-hmac-sha-00.txt

In this draft, we fill the authentication data with zeroes (look at
figure 2) before we perform any HMAC-SHA[1, 256, 384, 512] computation
(as defined in NIST FIPS 180-2 document).

My question is this:

Is there any harm in keeping some bits in the packet as 0, or does it
introduce any sort of vulnerability when some bits in the message to
be authenticated have zeroes in the data? This question stems from the
discussion that i was having with IETF participant who proposed
filling the authentication data (which we leave as 0) with some sort
of a constant (a random number agreed to by the two participating
routers).

Would we gain any advantage by filling some fields from the pkt by non
zeroes when using HMAC with NIST secure hash standard family of
algorithms? It would be most helpful if someone can give me some
pointers to such papers, etc.

Thanks,
Manav

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: David McGrew <[email-masked]>
Date: Fri, 13 Apr 2007 11:13:18 -0700

Hi Manav,

> pointers to such papers, etc.

I noticed this in the Security Considerations:

    There are certain hash functions that require all the fields of the
    message text T to be filled with non-zero values for greater
    security. Any extension using such hash functions to calculate the
    HMAC MUST fill the checksum field with some predefined non-zero
    number.

A nit: I think that you mean "MAC" instead of "hash function" in the  
first sentence.

It sounds like the idea is that, instead of zeroizing a mutable field  
prior to computing the MAC, the field would be filled by a random  
number instead.  Is that right?

I don't know any MACs with the property that is describe here.    
Including some random data instead of a string of zeros in the MAC  
input can't hurt, and in some cases might improve security.  But a  
MAC that couldn't handle a substring of zeros in its message input  
would not be secure against chosen-message attacks (in which an  
attacker could choose some of the messages processed with a  
particular MAC key, and could then use information gleaned from the  
MAC outputs to construct a forgery), and it really isn't appropriate  
to use such a MAC.

Hope this helps,

David