2
$\begingroup$

I am given a key exchange protocol between a component $C$ and a key master $K$. During the overall execution 4 messages are transferred between $C$ and $K$. DH keypairs are always chosen randomly for each execution.

Message (1) just contains the ID of the component. Message (2) contains the public-key of $K$ and a signature over the key that can be verified by $C$.

This message (2) can be easily replayed by an adversary. On the other hand a replay of (2) will be visible for $C$ after receiving message (4) from $K$ since message (4) contains a MAC whose key is derived from the freshly chosen private part of the DH-key pair (whose public part is contained in (2)).


I am asking myself whether it is a problem from the cryptographic / security point of view that (2) has not freshness protection but any replay will be noticed by $C$ at the end of the protocol execution.

$\endgroup$
  • $\begingroup$ You can probably prove that the protocol is secure, presuming the primitives are secure, although without a formal description of the protocol it will be hard to tell. On the other hand, there might well be practical issues, because you will only find out about problems in the protocol at a later stage, and at that time it may be hard to distinguish various issues. It may also hamper development because it has to take the possibility of earlier errors into account. That may hamper practical security in the end, of course. $\endgroup$ – Maarten - reinstate Monica Oct 21 at 4:44
  • $\begingroup$ I've been in a situation where you could only tell if key agreement was successful or not by looking at the MAC of received messages. I can tell you now that this was definitely not the right way to define the protocol; creating secure channel implementation that may have to report back to the authentication part of the protocol, but only for the first message ... not fun at all. $\endgroup$ – Maarten - reinstate Monica Oct 21 at 4:47
  • $\begingroup$ Thank for your answers! What I also noticed: An attacker can always inject random ID to get a signature over the public key (of $K$) and his own signature, since $K$ is not checking who is sending the message. So he may learn something about the secret signing key if he gets a lot of signatures ? $\endgroup$ – Marm Oct 21 at 6:27
  • $\begingroup$ Regarding the above question: can we conclude that freshness should always be provided for each message separately ? $\endgroup$ – Marm Oct 21 at 6:27

Your Answer

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

Browse other questions tagged or ask your own question.