4

Assume I have client and server applications with a shared master secret KEY_SECRET already in place. Also assume that the client and server have an implicit shared counter CTR initialized on the same value.

Is it wise to sign the data sent from the client to the server in a following way:

KEY_SIGN = HOTP(KEY_SECRET, CTR)
SIGNATURE = HMAC_SHA256(DATA, KEY_SIGN)

Client is technically able to compute the signature and server is able to validate it but I am wondering if this could have some hidden security / crypto / math side-effects.

Note: I assume "raw" HOTP format (4 bytes) here, not the decimalized version with the final "modulo D" that gives away the D-digit numeric code.

Note 2 (edit): As suggested in the comments below, using simply KEY_SIGN = HMAC_SHA1(KEY_SECRET, CTR) would gain much better key entropy.

otus
  • 32,462
  • 5
  • 75
  • 167
Petr Dvořák
  • 151
  • 4

1 Answers1

1

As mentioned by SEJPM in the comments, four bytes is much too short for an HMAC key.

Since KEY_SECRET is already in place, you could just use it directly as a MAC key, but then you need to make sure that DATA cannot collide with any counter value. You could do this by prefixing DATA with enough constant values to make it longer than the counter.

For example: MAC = HMAC(KEY_SECRET, 0x01 * 9 || DATA, where nine 1-bytes are prepended to make it longer than the eight-byte counter of HOTP.

otus
  • 32,462
  • 5
  • 75
  • 167