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
