I am reading about how to implement end-to-end encryption in IMs. Then I find this question. I cannot understand how the man-in-the-middle attack happens when the author of the answer says:

Note that this is still prone to man-in-the-middle attacks, so we will need an out-of-band method to verify that the two clients actually share the same key. This is often done by manually comparing hashed values of the keys (example: Signal).

Could you help me, please with more details, how the man-in-the-middle attack happens in this scenario?

  • I think what he is referring to is that a "man in the middle" could alter the key-exchange from the very beginning, to control the shared secrets required to decrypt all encrypted traffic. To make sure that a man in the middle did not modify the secrets, you need a method to transmit - or at least verify - a piece of data "out-of-band". Jun 14, 2019 at 2:37

1 Answer 1


Suppose the client software is trustworthy (after all, if it isn't, how do you know it doesn't send a copy of all your messages somewhere).

Everyone installs the client, it generates a new key pair each time, sends the public key to a directory service with the user's identifier (phone number, FB uid, whatever).

You want to send an encrypted message to me. You ask Signal's directory service (or Whatsapp, or whatever) for my public key. The directory service gives you a public key and says it's mine. You encrypt your message, send it to the chat service and I receive it and decrypt it using my private key. It works!

But, the directory service could have generated a new key pair, given you the public key, then when the chat service received the encrypted message, decrypted it, then encrypted it using my real public key (for which the private really only exists on my device), and sent it to me. We would not notice the small additional latency.

The way to check is to make sure the public key your client thinks is mine is the same one my client thinks is mine and to check that the public key my client thinks is yours is the same as the public key your client thinks is yours. If that is true (and the client software is itself trustworthy), you know the server does not do the MitM attack.

The way this verification is done differs between applications: Signal "verify safety numbers", Whatsapp "Verify Security Code", Wire "compare key fingerprints", etc.

There is a related attack, for example on iMessage, where I can be logged in on multiple devices, and when you encrypt your message to me, you actually encrypt it to multiple public keys, one for each of my devices. You get the list of all my public keys from the directory service. They can add a new key, as if I logged in on a new device, and your device will encrypt your messages to me to this key in addition to my other keys. But they control the new key. The way to protect would be to ensure new devices "joining the group chat" are visible to all other participants, but you can't. This is a UX tradeoff - the more secure the app is, the harder it is to use.

  • thanks by your reply but why one wat to verifiy is decrypting the message in the server, is this ok in the context of end-end to encryption?
    – juaninf
    Jun 14, 2019 at 10:23
  • 1
    If the server can decrypt the message, then it's no longer end to end, but that's the attack.
    – Z.T.
    Jun 14, 2019 at 11:57
  • understand, and what about "The way to check is to make sure the public key your client is using for encryption is the same one my client is using. If that is true (and the client software is itself trustworthy), you know the server does not do the MitM attack.". I do not understand why is necessary to check it? why my key-pair must be equal to you key-pair?
    – juaninf
    Jun 15, 2019 at 1:32
  • The key pair your phone thinks is mine must be equal to the key pair my phone thinks is mine.
    – Z.T.
    Jun 15, 2019 at 1:33
  • understand, is this verification done also for my key-pair, correctly? Normally, I see for example in Telegram that there is a key verification, but I think that it is a secret key (from a symmetric cryptosystem).
    – juaninf
    Jun 15, 2019 at 1:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .