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$
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 23:53

1 Answer 1

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 and acknowledge you have read our privacy policy.

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