Hi Padraic, Let me clarify: The construction described in the hubbub spec is this: H(m, k), where H is the hash function, m is the message, and k is the secret key. This is an 'append-only' hmac. The industry-standard HMAC (often just known as 'HMAC') is defined (in RFC2104) as H(k xor opad, H(k xor ipad, m)), where opad and ipad are fixed-length constants.
Apart from having been cryptanalyzed and proven secure under very weak assumptions for the underlying hash (see the paper referenced in the Wikipedia page), this hmac is already implemented in many languages - see the 'hmac' module in the Python standard library, for example. An example of an attack on an append-only HMAC is this: Suppose you can find a collision in your basic hash function, such that H(a) == H(b). Now, if you can persuade someone to generate a valid HMAC for the innocent message H(a), you can use it as an HMAC for the malicious message b. The RFC2104 HMAC does not have this weakness, due to its nested construction. -Nick Johnson On Thu, Oct 8, 2009 at 1:22 PM, Pádraic Brady <[email protected]>wrote: > You might need to explain what you mean in greater detail. You say the use > of a HMAC is ad-hoc and then refer to the concatenation of the secret to the > request body. Yet, HMAC does not actually define the information format to > be exchanged (how could it possibly do so?), so simple concatenation seems > entirely reasonable since it a) fully represents the information both > parties are exchanging and b) must be defined by the specification to ensure > interoperability between implementations. > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative<http://www.openideurope.eu/> > > > ------------------------------ > *From:* Nick Johnson (Google) <[email protected]> > *To:* [email protected] > *Sent:* Thu, October 8, 2009 8:51:56 AM > *Subject:* [pubsubhubbub] Re: Use of HMAC for authenticated content > distribution > > On Thu, Oct 8, 2009 at 3:38 AM, Sachin Shenoy <[email protected]>wrote: > >> I am bit confused here. SHA in SHA-1 stands for Secure Hash Algorithm. Why >> do you say it is ad-hoc? > > > I'm not saying the hash algorithm itself is ad-hoc, I'm saying its use as > an HMAC is ad-hoc. RFC2104 defines an accepted (and proven secure) way of > constructing an HMAC, which is far preferable to the simple concatenation > approach taken here. > > -Nick > > >> If you meant "Why don't we support other hash function [configured/chosen >> by a param], instead of just supporting SHA-1?" - I think that has to do >> with this line from spec. >> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html >> "To dramatically simplify this spec in several places where we had to >> choose between supporting A or B, we took it upon ourselves to say "only A", >> rather than making it an implementation decision." >> >> Thanks, >> Sachin >> >> >> On Thu, Oct 8, 2009 at 2:15 AM, Nick Johnson (Google) < >> [email protected]> wrote: >> >>> The hubbub spec, in section 7.4, says: >>> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#authednotify >>> >>> "The signature MUST be computed by appending the hub.secret value to the >>> request body and then generating the combined string's HMAC using the SHA1 >>> algorithm." >>> >>> However, HMAC has a specific definition, in RFC2104, which allows for >>> composing HMACs from secure hash algorithms. It's constructed specifically >>> to make it more difficult to forge or brute-force an HMAC, a property the >>> description in the hubbub spec lacks. >>> >>> Why does the hubbub spec use this ad-hoc construction instead of a proper >>> HMAC? >>> >>> -- >>> Nick Johnson, Developer Programs Engineer, App Engine >>> Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration >>> Number: 368047 >>> >> >> > > > -- > Nick Johnson, Developer Programs Engineer, App Engine > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
