On Thu, Oct 8, 2009 at 2:26 PM, Pádraic Brady <[email protected]>wrote:
> 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. > Good point. Examining the source, it would appear that hubbub already uses the standard hmac: *http://tinyurl.com/yawbxec - which makes this simply a documentation issue. :)* -Nick > > Paddy > > 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 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<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 > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
