3
$\begingroup$

Suppose two agents A and B share a common secret and A makes a regular unique 16-byte announcement to B every 10mins which B must verify authenticity.

I'm thinking of letting the first 8 bytes be the message and the last 8 bytes be the HMAC(key, msg). The message itself contains an increasing counter, which B uses to reject all future messages with a lower counter.

Given the uniqueness of each message and the strict monotonicity of the counter, should this scheme avoid replay attack?

Overall, is this a secure approach?

Thanks

$\endgroup$
  • 1
    $\begingroup$ I believe the counter alone defeats the replay attack as long as it is protected by the HMAC so it cannot be altered by an attacker. $\endgroup$ – WDS Sep 24 '15 at 10:27
  • $\begingroup$ I see. Will it still be secure if the master key, which after being salted is used derive a key to sign messages, is shared over a public channel? $\endgroup$ – Kar Sep 24 '15 at 15:59
  • $\begingroup$ The master key is transmitted over a public channel? That doesn't sound good. What would prevent an attacker from deriving the HMAC key, e.g. is the salt being kept private? (typically, salts are assumed to be public) $\endgroup$ – Tim McLean Sep 24 '15 at 19:41
  • $\begingroup$ Yes, the salt is kept private - hard coded in all agents. So the KDF derives keys from a salted master key. $\endgroup$ – Kar Sep 24 '15 at 23:53
1
$\begingroup$

[let] the last 8 bytes be the HMAC(key, msg)

64 bits is a pretty small tag size, and not considered "cryptographically strong". I would suggest using the full HMAC output if possible, or see here for some discussion of reduced tag length.

should this scheme avoid replay attack?

Assuming that the HMAC cannot be broken (which would imply that the key is kept secure and a sufficient tag size is used), this scheme looks fine against replay attacks.

(I suggest opening a new question with regard to your key derivation scheme)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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