6

In RFC 4226, the algorithm for HOTP is described as follows:

HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))

TOTP is essentially the same algorithm as HOTP except for the fact that the counter "C" is replaced by an integer derived from the current time (in Unix Time). In the words of RFC 6238,

Basically, we define TOTP as TOTP = HOTP(K, T), where T is an integer and represents the number of time steps between the initial counter time T0 and the current Unix time.

However, the reference code described in RFC 6238 as well as the test values listed in Appendix B has reference to HMAC-SHA256 and HMAC-SHA512. The two algorithms are not mentioned anywhere else in either RFC 4226 or RFC 6238 though.

My question - Are HMAC-SHA256 and HMAC-SHA512 officially supported as variants of the HOTP and TOTP algorithms?

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42

2 Answers2

5

It's not only the code sample and the test values, it's even there explicitly in the RFC 6238:

TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions, instead of the HMAC-SHA-1 function that has been specified for the HOTP computation in [RFC4226].

So, yes.

My inexperienced but slightly educated guess would be that there's nothing wrong with using them even with HOTP (even though the RFC doesn't explicitly say it). After all, HOTP and TOPT are virtually the same.

Community
  • 1
Adi
  • 43,808
  • 16
  • 135
  • 167
3

Obviously, these two hash algorithm aren't supported by the standard. In fact, SHA-1 is used pretty much everywhere in RFC 4226 so, if you replace it with another hash, you'll be implementing a different system.

Furthermore, I wonder what would be the idea behind this: the implementation calls for the result of the HMAC to be truncated and the initial HMAC uses a very short secret: using a different hash algorithm here wouldn't improve security but it would make it incompatible with existing applications and tokens.

edit: RFC 4226 is pretty clear about what algorithm you can use: HMAC-SHA-1 (section 5.2) so, if you must support RFC 4226, you can't use anything else.

RFC 6238, on the other hand, opens the door to the use of SHA-256 and SHA-512 (in section 1.2).

Therefore, it looks like it all depends on your requirements: if you're implementing RFC4226 (HOTP) or must be compatible with it, you cannot use anything but HMAC-SHA-1. If, however, you're implementing RFC 6238 (TOTP), using HMAC-SHA-256 or HMAC-SHA-512 is within the scope of the standard.

otus
  • 657
  • 6
  • 13
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • "Obviously, these two hash algorithm aren't supported by the standard." So *why* is `HMAC-SHA256` and `HMAC-SHA512` described in RFC 6238? Test vectors are even provided. –  Nov 22 '13 at 13:21
  • Good question. if you check section 1.2 of RFC 6238, it tells you that you can use HMAC-256 or HMAC-512 in the context of that RFC (but not 4226). Therefore it looks like you could use these for TOTP but not HOTP. I still don't see how it would improve the security of the whole thing though. – Stephane Nov 22 '13 at 13:25
  • Yes, not questioning the point about improving security. My question is more about finding out if the algorithms are *officially* supported by the RFC. Given that TOTP is essentially the same algorithm as HOTP, won't the two algorithms work for HOTP as well? –  Nov 22 '13 at 13:26
  • I clarified my answer. – Stephane Nov 22 '13 at 14:01