Assume that A and B have exchanged their public keys beforehand. Now, A and B wants to communicate over an insecure channel and want to provide integrity and confidentiality on the message. A use the shared secret calculated using DH to encrypt the message using a symmetric cipher. If B can decrypt the message, can B be assured that this message is written AND encrypted by A?


migrated from security.stackexchange.com Oct 27 '16 at 11:16

This question came from our site for information security professionals.

  • $\begingroup$ Are you asking whether such a system is cryptographically possible (yes it is and it is what crypto_box in NaCl is doing)? $\endgroup$ – SEJPM Oct 27 '16 at 12:01

In general the answer is no.

First, you need to make sure that your DH key agreement is authenticated. Otherwise you have no guarantee that you are talking to A at all.

Second, the symmetric cipher you use needs to provide authenticity so you should use some AEAD scheme. Otherwise somebody could just change the symmetrically encrypted messages.


Your setup is:

  • Alice and Bob have each other's public key
  • They use DH for the key exchange
  • They want confidentiality and integrity

In its original form, DH key exchange does not use public keys, and there is no authentication. What you want for communication in both directions between two parties is mutual authentication, for example with authenticated DH, but there are alternatives. TLS usually is authenticated only on one side, so that doesn't work.

Now with that key from the kex exchange you can use KDF in order to get two keys: One for encryption and one for the MAC.

Now comes the difficult question: MAC-then-encrypt vs encrypt-then-MAC? (link to a question on crypto-SE)
From the asnwers in the link, the suggestion would be encrypt-then-MAC, if you want to use one of them.

Constructions like this are usually called authenticated encryption, with the focus on the mode of operation and how the MAC is included in that. Other examples are GCM and EAX.

If you want to use digital signatures for integrity, then there is also signcryption.

On a final note: While not in the question, it might be interesting to get the forward secrecy property in your protocol. This is usually adressed by using a matching key exchange protocol.


Are you inventing TLS or are you inventing WhatsApp?

If they have exchanged public keys beforehand (offline), then their DH key exchange will be signed by their public keys for authentication. They will use the shared secret in a KDF to generate symmetric keys used for encryption and authentication of the messages.

Unauthenticated encryption is completely useless because encryption is malleable. In modern protocols they would use AEAD instead of manually combining encryption and MAC.

When receiving the encrypted message, the MAC is checked first and if it's valid then the message was encrypted by someone who knows the shared secret and that could only be the other party. So yes, if the DH was digitally signed by the right key.

Please use TLS, or libsodium, or signal protocol.

  • $\begingroup$ As much as this advice is sound, it doesn't really answer the question. $\endgroup$ – Polynomial Oct 27 '16 at 9:58
  • $\begingroup$ @Polynomial "So yes, if the DH was digitally signed by the right key." $\endgroup$ – Z.T. Oct 27 '16 at 10:47
  • $\begingroup$ While the concepts can be inductively applied, you're conflating authenticity and integrity. There are a number of key caveats in a correct answer to OP's question, which is why I suggested it be migrated to Crypto.SE. $\endgroup$ – Polynomial Oct 27 '16 at 11:11
  • $\begingroup$ @Polynomial for my benefit, what's the difference between my answer and the correct answer? Doesn't MAC guarantee authenticity too, if MAC key derived by KDF from DH shared secret and DH was digitally signed? $\endgroup$ – Z.T. Oct 27 '16 at 16:19
  • $\begingroup$ Don't look at me; I didn't accept the answer. $\endgroup$ – Polynomial Oct 27 '16 at 16:53

Your Answer

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