Yep this is a missing piece of documentation. I'll add an issue to get a fix in the 0.3 spec. Thanks for the close read and discussion, everyone!
2009/10/8 Pádraic Brady <[email protected]>: > Hi Nick, > > I will agree on one thing, the specification should probably clarify what it > means by "HMAC". My own reading of the specification was that 7.4 referred to > HMAC-SHA1, not simply SHA1. But then, like yourself, I always assume HMAC > refers to the relevant RFC, and not simply a salted hash which, using SHA1 > alone, has few of the benefits offered by a proper HMAC. > > Incidentally, as far as I can recall, the reference hub was using Python's > hmac. The part I'm not sure on that specification indicates appending the > secret to the request data which seems either incorrect or redundant, and > more akin to how you'd expect a salted hash to function. I'm only now adding > in 0.2 changes to my own source code Subscriber/Hub so I really haven't had > time to test how it operates with the reference hub. > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative > > > ________________________________ > From: Nick Johnson (Google) <[email protected]> > To: [email protected] > Sent: Thu, October 8, 2009 1:31:37 PM > Subject: [pubsubhubbub] Re: Use of HMAC for authenticated content distribution > > 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 >> >> >> ________________________________ >> 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 >
