Having successfully install and verified correct operation of 1.6.2 from source on centos 5.5(32 bit) fully patched for HOTP
I proceeded to test with TOTP Where I became concerned that against a single Android based client (Android Token) authentication was failing.
Next step was to test each of the Test Vectors in turn at this point
These test vectors were taken from revision 6 RFC and are reproduced below:
The test token shared secret uses the ASCII string value "12345678901234567890". With Time Step X = 30, and Unix epoch as initial value to count time steps where T0 = 0, the TOTP algorithm will display the following values for specified modes and timestamps.
Time (sec) | UTC Time | Value of T (hex) | TOTP | Mode |
59 | 1970-01-01 00:00:59 | 0000000000000001 | 94287082 | SHA1 |
59 | 1970-01-01 00:00:59 | 0000000000000001 | 32247374 | SHA256 |
59 | 1970-01-01 00:00:59 | 0000000000000001 | 69342147 | SHA512 |
1111111109 | 2005-03-18 01:58:29 | 00000000023523EC | 07081804 | SHA1 |
1111111109 | 2005-03-18 01:58:29 | 00000000023523EC | 34756375 | SHA256 |
1111111109 | 2005-03-18 01:58:29 | 00000000023523EC | 63049338 | SHA512 |
1111111111 | 2005-03-18 01:58:31 | 00000000023523ED | 14050471 | SHA1 |
1111111111 | 2005-03-18 01:58:31 | 00000000023523ED | 74584430 | SHA256 |
1111111111 | 2005-03-18 01:58:31 | 00000000023523ED | 54380122 | SHA512 |
1234567890 | 2009-02-13 23:31:30 | 000000000273EF07 | 89005924 | SHA1 |
1234567890 | 2009-02-13 23:31:30 | 000000000273EF07 | 42829826 | SHA256 |
1234567890 | 2009-02-13 23:31:30 | 000000000273EF07 | 76671578 | SHA512 |
2000000000 | 2033-05-18 03:33:20 | 0000000003F940AA | 69279037 | SHA1 |
2000000000 | 2033-05-18 03:33:20 | 0000000003F940AA | 78428693 | SHA256 |
2000000000 | 2033-05-18 03:33:20 | 0000000003F940AA | 56464532 | SHA512 |
The following syntax was used to verify the values against the SHA1 entries from the table above,
These values were fine but for all but the last entry.
Both the command and the resultant output are shown below
# oathtool --totp -v -N "2033-05-18 03:33:20" 3132333435363738393031323334353637383930 -d 8
Hex secret: 3132333435363738393031323334353637383930
Digits: 8
Window size: 0
Step size (seconds): 30
Start time: 1970-01-01 00:00:00 UTC (0)
Current time: 2033-05-18 02:33:20 UTC (1999996400)
Counter: 0x3F94032 (66666546)
48573438
Conclusion It is apparent that both the calculated time since epoch value is in error leading to the wrong computation. When I adjust the time so that Current time has value of 2000000000 ie 2033-05-18 03:33:20 I do get the correct output value of 69279037 |
|
|
Martin Brett
Voice and Network Engineer
thebigword - Translation, Interpreting and Technology
Link Up House, Ring Road, Lower Wortley, Leeds, LS12 6AB
DD: +44 (0)113 210 7514 T: +44 (0)870 748 8000 W: www.thebigword.com |
P Please consider the environment before printing this email.
thebigword Holdings Limited. Registered Office: Link Up House, Ring Road, Lower Wortley, Leeds, UK, LS12 6AB. Registered in England & Wales No. 05551907.
This document is strictly confidential and is intended only for use by the addressee. If you are not the intended recipient, any disclosure, copying, distribution or other action taken in reliance of the information contained in this email is strictly prohibited. Any views expressed by the sender of this message are not necessarily those of thebigword Holdings Limited and its subsidiary companies. If you have received this transmission in error, please use the reply function to tell us and then permanently delete what you have received.
|
|
|
|
|
|
|