pasamio / oathtoken

Automatically exported from code.google.com/p/oathtoken
0 stars 0 forks source link

Generated keys do not match expected output #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Specify the secret key 12345678901234567890 (as defined in the specification 
- http://tools.ietf.org/html/rfc4226)
2. Set count to 0
3. Generate pin

What is the expected output? What do you see instead?

Expected:

Count-Pin
0-755224
1-287082
2-359152
3-969429

Actual:

Count-Pin
0-803282
1-039425
2-233531
3-573854

What version of the product are you using? On what operating system?

1.0.1 on iPhone 3G 3.1.3

Please provide any additional information below.

I feel like I'm insane since no one else seems to have noticed the issue. But i 
checked and double checked and triple checked. At first i thought it was my 
code, but i generated a table of pins for incrementing keys. I compared it to 
the test case in the RFC and they match EXACTLY. I googled for an online 
javascript version and the results i get are the same as the RFC and the code i 
have. Am i hallucinating? Surely someone else must have noticed this since we 
are all following the same spec here....

Original issue reported on code.google.com by yumek...@gmail.com on 26 Jul 2010 at 5:43

GoogleCodeExporter commented 9 years ago
Ok i think i am insane. I just tried ioath token and the results match those of 
oathtoken. What going on?? How can the documented test case in the official RFC 
spec differ from those that programs written implementing that spec generate? 
Am i missing something?

Original comment by yumek...@gmail.com on 26 Jul 2010 at 5:51

GoogleCodeExporter commented 9 years ago
Mobile-OTP for Android confirms my initial response. The output of that matches 
mine and the RFC.

Original comment by yumek...@gmail.com on 26 Jul 2010 at 6:17

GoogleCodeExporter commented 9 years ago
My guess is you are entering the key wrong. The key in the RFC is expressed as 
an ASCII string "12345678901234567890". But in hexadecimal binary - the format 
used by OATH Token and mod-authn-otp, that would be: 
"3132333435363738393031323334353637383930".

You can verify things match the RFC using the "otptool" utility from 
mod-authn-otp:

{{$ for i in 0 1 2 3 5 6 7 8 9; do otptool -c $i 
3132333435363738393031323334353637383930; done
0: 755224 93cf18
1: 287082 397eea
2: 359152 2fef30
3: 969429 ef7655
5: 254676 c083d4
6: 287922 56c032
7: 162583 e5b397
8: 399871 23443f
9: 520489 79dc69
}}

Original comment by archie.c...@gmail.com on 26 Jul 2010 at 7:10

GoogleCodeExporter commented 9 years ago
aaaaaaaaahhhh thank you :)) A little confusing how different projects use 
different formats. Glad I'm wasnt crazy.

Original comment by yumek...@gmail.com on 26 Jul 2010 at 9:32