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
