I have to design a secure keep alive communication protocol and was wondering if it was necessary to sign the ciphertext after the session key has been generated as an attacker will not know the key.

Protocol Overview:

  1. Both the client and server have a copy of their respective public keys.
  2. Generate session key using ECDH. Parameters will be signed and sent to both parties.
  3. Further communication encrypted with AES in GCM mode. IV and Tag are appended to the ciphertext and sent to the other party.

Side Note:
How can I introduce forward secrecy?

  • $\begingroup$ If you create a key as in step 2 and use it only once, it is forward secrecy $\endgroup$ – kelalaka Jul 14 at 13:56
  • 1
    $\begingroup$ GCM uses a (96 bit) nonce rather than an IV. You may want to make sure that you use a 12 byte nonce. GCM is a bit brittle: it breaks easily when abused. You may want to be sure it is used within the specified bounds (nr of messages, message size, etc.). $\endgroup$ – Maarten Bodewes Jul 14 at 17:49

I ... was wondering if it was necessary to sign the ciphertext

No, there is no need to sign the ciphertext. The secret key is already derived by the key agreement protocol, and that is secure because you verified the parameters (which, I presume, includes the ephemeral public key of each party).

At this point you just have to verify that each party does indeed have the same shared secret. One way to do this is to verify a GCM encrypted message.

The problems with that are that:

  1. you need to send a message (which could take some time after you've agreed upon a key) and
  2. you're now mixing up entity authentication and message authentication.

Part 2 is a major pain in the back for developers and maintainers as they will have to mix concepts. For instance, what will you log if the first message fails? Was it data corruption for the - often much larger - authenticated message or was it a failure to establish the session in the first place?

So you're probably better off sending a MAC specific to entity authentication to the other party as soon as the shared secret is established, preferably using a different derived authentication key. You can use a KDF to e.g. establish an authentication key and message encryption key for that purpose.

The first MAC can be send with the ephemeral public key that is exchanged last; at that point one party already has the other party's public key and can establish the shared secret after all. Unfortunately it may cost you an additional message if the other party needs to be authenticated quickly. Of course there are solutions to that as well, but yeah...

How can I introduce forward secrecy?

If you used ephemeral (EC)DH key pairs for both parties to establish the session keys then you already have obtained forward secrecy. Of course this assumes that you destroy the ephemeral private keys asap after establishing the session keys.

Note that sessions are not immune to attack where the private keys are found e.g. by quantum computers in the future. Forward secrecy is not a panacea (which is why I generally stick with "forward secrecy" rather than "perfect forward secrecy" even though the "perfect" part isn't related to breaking the key agreement algorithm).


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.