2
$\begingroup$

I am really confused and need help on this problem related to TOTP as specified in RFC6238 here: https://tools.ietf.org/html/rfc6238#section-1.2.

So I am now given a task to implement the RFC6238 to generate a 10-digit TOTP password, which will be used in a POST request later on. The sample input and output for the TOTP is supposed to be like this:

Sample Input:

Shared key: "ninja@example.comHDECHALLENGE003" (without double quotes)

Hash function used: HMAC-SHA-512

T0 = 0, Timestep = 30 seconds (as per specified in RFC6238)

Expected TOTP of 10 digits

Sample Output:

Successful TOTP generated: 1773133250, for time of Mon, 17 Mar 2014 15:20:51 GMT

base64 encoded POST Authorization username/password request: bmluamFAZXhhbXBsZS5jb206MTc3MzEzMzI1MA==

(I have decoded the sample POST authorization to be 'ninja@example.com:1773133250' hence why I can say that the sample TOTP output is 1773133250)

Now the problem that I have is after attempting to make my own script according to the rfc6238 specification I cannot get the same output for the sample input as above. I then tried using other available online TOTP modules that area available online (mostly in Python), to find that they generate the same output as the script that I have created. Finally, I then tried to outright copy and run the Java code given in the example of RFC6238 and came up with the same result as my script, i.e.:

Attempted input:

Hex Encoded seed for HMAC512: "6E696E6A61406578616D706C652E636F6D4844454348414C4C454E4745303033" + "6E696E6A61406578616D706C652E636F6D4844454348414C4C454E4745303033";

Time inputted is 1395069651L, representing the time received in sample output

Result of attempt (same output from custom script, other Python modules, and the Java implementation given in RFC6238 documentation):

Generated TOTP: 0490867067

I am really confused now as I believe that I have followed the instructions given by the task, and even used the actual RFC given Java code to only then find that they are not generating the same ouput as the one given in the task. I have then contacted the provider of the task to know if there is any bug, but they say that it is already correct.

Perhaps I am missing something here, such as the way the task provider actually encrypts the shared key? I am very new to this and any knowledge on any caveats such as different key encryptions resulting in different TOTP would be really appreciated.

Really appreciate any help related to this, and to give me better understanding on this TOTP manner! Thank you :)

|improve this question
$\endgroup$
  • 1
    $\begingroup$ I would very much make sure that this is not an encoding issue. Do you need to process hex representation itself or the binary representation? Do you use the same text encoding? In other words, look at anything that can influence the input to the programs you tried. Otherwise, I don't see what we can do there; you've specified an RFC and both your code and 3rd party code complies with it. What can we do about this situation? $\endgroup$ – Maarten - reinstate Monica♦ Mar 2 '17 at 14:21
  • $\begingroup$ Hello, sorry for the late reply! Hmm, I am not too sure whether the text encoding that the task provider uses is the same or not, since they do not specify it on the page that they have given me either. I am assuming that they are using the normal text-encoding that was used on the Linux kernels, so I am not too sure... Could you elaborate more on what is the potential encoding issue that could be had when inputing the shared key into the script Maarten? Thank you and sorry if my answer is unsatisfactory $\endgroup$ – Nicholas Sadjoli Mar 3 '17 at 3:44
  • $\begingroup$ Also, as can be seen in the original post that I made, I am processing a hex representation (i.e. hex encoding) of the key into the script. Though I do understand that there could be other representations that is going on. I've just realized too that I am using a representation that is the output of an hex Encoding actually. Would this be different from hex representation of the key? Thanks $\endgroup$ – Nicholas Sadjoli Mar 3 '17 at 3:50
  • $\begingroup$ Yes, usually the hexadecimals are just used to represent the underlying byte array. If you process the hexadecimals (the binary as text) instead then you get a different output. Same goes for the key. There may also be text encoding differences for ninja@example.com:1773133250 although I'd assume something that is ASCII compatible if you're already used several implementations, so that is less likely. Maybe post your code on StackOverflow then we can see what could be wrong. Note that a few protocols also confuse hexadecimals and binary, but those are fortunately not that common. $\endgroup$ – Maarten - reinstate Monica♦ Mar 3 '17 at 8:24
  • $\begingroup$ Dear Marteen, thank you for your reply. For the code, in the end i have been using the Java code provided by the RFC 6238 group actually, which I think you can accesss from the link I have.. However, yeah sure, I would like to post the code that I wrote too then. I actually have posted the same question there. Do you have the link to that post, or should I just create a new one? Also, how should I notify you if I do make a new post like that eh? (Sorry I am new here lol) $\endgroup$ – Nicholas Sadjoli Mar 4 '17 at 22:42