# Is key derivation of a token shared secret necessary for usage of token in TOTP as specified by RF6238?

TL;DR: Is it necessary to generate a 'random' key from a shared token secret string before putting it into a TOTP algorithm that follows the RFC 6238 specification? Or is it okay for me to put the token secret directly into the TOTP algoritm (of course with proper base32 or hex format depending on the algorithm used)?

Long Version:

Hello, currently I am trying to solve a challenge that relates to me generating the correct 10-digit TOTP based on my userid and certain string combinations. However, currently I cannot seem to generate the correct output, even though I have followed the RFC 6238 specification correctly (as can be seen here: https://tools.ietf.org/html/rfc6238#section-1.2), and even borrowed the code provided in the RFC to generate the TOTP.

As some background, the task provider has given me a sample input and output like specified below:

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

(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)

In an attempt to replicate this result, I inputted the shared key "ninja@example.comHDECHALLENGE003" into the totp algorithms that I used with a hex representation of the key, i.e. 6E696E6A61406578616D706C652E636F6D4844454348414C4C454E4745303033, especially for the TOTP algorithm that is shown in the RFC 6238. Unfortunately it seems that I cannot get the correct result and instead got the output like this:

Attempted input:

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

Time inputted (the message that is going to be hashed) 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

After some more reading though, I have noticed that it seems that the token shared key/secret that is entered into the TOTP main function (i.e. the one that is going to be encoded into SHA-512) derived from a random generator or a key derivation function, according to the RFC 6238. With this in mind, my main question then would be (sorry after a long explanation haha):

Is it possible and actually necessary for me to first input the shared token to a key derivation function first, before then inputting it into the TOTP algorithm (i.e. do the Key Derivation first, then input into the SHA portion of the TOTP)? If so, should I then use the same shared key as he salt of the key derivation function?

• Could it be, that the shared secret you have to use, is actually "HDECHALLENGE003" and not "ninja@example.comHDECHALLENGE003"? – mat Apr 6 '17 at 15:21
• Hey mat, sorry for the late reply. I believe I have tried using that secret instead but it didn't work. Do you think that the shared secret given is in a weird format? :( – Nicholas Sadjoli Apr 8 '17 at 9:12
• Hey nicholas, I have also have the same problem. Can you tell me what shared token secret string you used to get the 1773133250 as TOTP. Because i get wrong TOTP when i use 6E696E6A61406578616D706C652E636F6D4844454348414C4C454E4745303033 as shared key. – Sho_arg Jan 24 '19 at 16:03

• 10 digits won't really work well. The OTP is calculated from a 32 bit integer value. And since $2^{32} \approx 4\cdot 10^9$ more than half of the password space will never be used. – mat Apr 8 '17 at 11:54
• You can make a OTP of any length, it just doesn't make much sense. The process in HOTP/TOTP ist, that the so called dynamic truncation function selects 4 bytes from the hash value, converts the last 31 bot of that into a decimal value and the OTP is then this value $mod 10^{digits}$ and pad the results with zeroes in the beginning. Digits can theoretically be any value you like, 10 or even higher. But if its larger than 8, you have to be prepared that the leftmost digits of your passwords will be zero most of the time, so they hardly add any security value. – mat Apr 12 '17 at 8:37