4
$\begingroup$

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.

$\endgroup$
4
  • 1
    $\begingroup$ You're using a 4-byte (32 bit) value as your key for HMAC (trivially brute-force able on home computers). I'd avoid that if possible although your construction may prevent attacks with better than $2^{-32}$ success probability. $\endgroup$
    – SEJPM
    Commented Nov 3, 2015 at 20:25
  • $\begingroup$ Thank you, you are absolutely right - I am trying too hard to find some "straightforward building blocks". Instead of doing what I just wrote above, I could include CTR in DATA and use HMAC directly, as such: SIGNATURE = HMAC_SHA256(KEY_SECRET, COMBINE(DATA, CTR)), or alternatively, I could strip HOTP down one step further to simply use HMAC to derive N-th KEY_SECRET - that way I would at least keep reasonable entropy (since I would lose the TRUNCATE step). $\endgroup$ Commented Nov 3, 2015 at 20:51
  • 2
    $\begingroup$ If you'd strip the TRUNCATE step it should be reasonably secure. I suggest editing this into your question. $\endgroup$
    – SEJPM
    Commented Nov 3, 2015 at 21:17
  • 1
    $\begingroup$ I edited your tags, because by signatures we usually mean public-key signatures. What you are using is a MAC. $\endgroup$
    – otus
    Commented Nov 4, 2015 at 8:32

1 Answer 1

1
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.