I've filed this issue to track it in the spec: http://code.google.com/p/pubsubhubbub/issues/detail?id=90
On Fri, Oct 16, 2009 at 9:32 PM, Brett Slatkin <[email protected]> wrote: > 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 >> >
