Problems calculating signature

[Dag Arneson]

We've had such a collection for a while, actually.  In the python 
library it lives at: openid/test/*.txt
There are trustroot, uri normalization and (old-style) link tag parsing 
test cases there.  Suggestions on how to keep this test data synced 
between ports are certainly welcome.

Dag

Marius Scurtescu wrote:
> Another side note, on the meta-issue,
> 
> I think it would be helpful to have a collection of test cases that  
> are language and implementation independent. These test cases could  
> be expressed in xml files for example.
> 
> For signatures this will consist of sets of parameters and keys and  
> expected signatures. Your implementation will have to parse the xml  
> file, generate signatures and compare against expected values.
> 
> The set of tests can be extended as we go and we can create similar  
> test cases for other areas of the protocol. We just created such a  
> test case for trust root matching and we plan to share it between our  
> Java and the Perl implementations (if anyone is interested I can send  
> these trust root matching test cases).
> 
> This will assure that your code can interoperate with other  
> implementations and that we have a comprehensive set of tests (every  
> time someone runs into some obscure case that can be added to the  
> shared test case and all implementations will benefit).
> 
> Not sure what the best way would be to share these tests.
> 
> Marius
> 
> On 5-Sep-06, at 11:01 AM, Johannes Ernst wrote:
> 
>> I'd be great if somebody volunteered to write down the complete set  
>> of steps to do the OpenID crypto, and annotated it with an actual  
>> numeric example for each step.
>>
>> Our experience at NetMesh implementing OpenID for InfoGrid was  
>> similar to Thom's -- it took at lot longer than expected until we  
>> got it working, but then only 9 out of 10 times. It took a few  
>> months of cursing (and lots of help) before we realized that there  
>> was a leading-zero problem in one of the steps that would only  
>> occur rarely depending on the mood of the random generator.
>>
>> A numerically-annotated set of steps would be really helpful.  
>> Actually, several annotations to catch things like leading zeros,  
>> negative numbers etc. etc. would be even more so.
>>
>> [Sorry Thom I can't help you with this issue, but I hope this helps  
>> with the meta-issue ...]
>>
>> On Sep 5, 2006, at 3:23, Thom McGrath wrote:
>>
>>> Hi list,
>>>
>>> I've been developing an OpenID server & consumer for my web site (I
>>> prefer doing things myself) and everything is working wonderfully,
>>> except my signatures never come out the same as the "other end's"
>>> signature. I even brought my friend Kris in on this, who has worked
>>> with this stuff before, and the two of us combined could not figure
>>> it out.
>>>
>>> I'm pretty sure it's not the HMAC-SHA1 hashing algorithm because I
>>> copied it from the JanRain libraries. But I am completely stumped on
>>> this one, so it could be anything. So I've included the relevant
>>> code. Does anybody notice any problems?
>>>
>>> function createSignature ($key, $data)
>>> {
>>> 	$token = "";
>>> 	$a = explode(",",$data['openid_signed']);
>>> 	foreach ($a as $f) {
>>> 		$token .= $f . ':' . $data['openid_' . str_replace(".","_",$f)] .
>>> "\n";
>>> 	}
>>> 	return base64_encode(createHMACSHA1String($key,$token));
>>> }
>>>
>>> function createHMACSHA1String($key, $data)
>>> {
>>> 	if (strlen($key) > 64) {
>>>          $key = sha1($key,true);
>>>      }
>>> 	
>>>      $key = str_pad($key, 64, chr(0x00));
>>>      $ipad = str_repeat(chr(0x36), 64);
>>>      $opad = str_repeat(chr(0x5c), 64);
>>>      $hash1 = sha1(($key ^ $ipad) . $data, true);
>>>      $hmac = sha1(($key ^ $opad) . $hash1, true);
>>>      return $hmac;
>>> }
>>>
>>> $sig = createSignature(base64_decode($secret),$_GET);
>>>
>>> I've already done lots of debugging. The secret does match the one
>>> that came from the server during the 'associate' method. This code is
>>> in response to a 'checkid_setup' method. The reason the fields say
>>> 'openid_signed' instead of 'openid.signed' is because PHP converts
>>> the '.' characters to underscores. The proper keys are being
>>> calculated in the keyvalue string (sreg.nickname, not sreg_nickname).
>>>
>>> I have been testing this using a MyOpenID.com account I setup, so I'm
>>> assuming the server end is doing it's job correctly.
>>>
>>> Does anybody know what I'm doing wrong?
>>>
>>> --
>>> Thom McGrath, <http://www.thezaz.com/>
>>> "You realize you've created God in your own image when God hates all
>>> the same people you do."
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>> Johannes Ernst
>> NetMesh Inc.
>>
>> <lid.gif>
>>  http://netmesh.info/jernst
>>
>>
>>
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> 
>