Potentially Risky Representation of Encrypted Messages

[H-MAli]

Users are now notified of whether the received message is encrypted using an Emoji:

  if (textNodeContent.startsWith(config.ENCRYPT_PREFIX)) {
    changeTextNode(target, "Parsing ...");
    try {
      const packet = await cipher.resolveDRSAP(textNodeContent);
      if (!packet) changeTextNode(target, "⛔ Error in decryption");
      else changeTextNode(target, "🔒" + packet);
      (target as any).dir = "auto";
    } catch (error) {
      changeTextNode(target, "⛔ Error in decryption");
    }
    return;
  }

This poses some inherent issue. Imagine the scenario where a MITM is blocking messages to reach the recipient, and forging some plain messages and sending them back with the used Emoji. There wouldn't be a definite way of telling a forged message apart from a real decrypted one unless the user toggles the entire functionality off to see the original messages.

Now, what would the risk be?
Imagine the following conversation from the MITM's perspective:

Incoming: [ENCRYPTED MSG]
MITM - Outgoing: 🔒سلام.
Incoming: [ENCRYPTED MSG]
MITM - Outgoing: 🔒خوبی؟
Incoming: [ENCRYPTED MSG]
...

If the MITM can force some predictable answers for long enough, guessing the shared symmetric key would be more and more doable. They would then return the flow of the conversation back to normal (i.e., end blocking of messages), and try to tap into the conversation.

One might say that the disconnect in the conversation would be reason enough for the user to get a clue, but lots of people would disregard it as some "general error" of some sort.

I suggest using a unique and animated icon, or a set of Emojis that are the product of the shared symmetric key (like what you would see in a Telegram voice/video call).

[mostafa-kheibary]

I changed the simple 🔒 indicator to have an opacity of 0.5. With this new style, you can recognize if the user put the emoji themselves or if it is the valid encryption indicator that ChatGuard placed there.

I will show a set of emojis based on the public key to verify your public key with the recipient. Every public key will generate a unique set of emojis to identify and verify it.

Additionally, with the new encryption algorithm, I removed the prefixes and now send the encrypted messages as Base64 encoded text. This makes it harder for a MITM (Man-In-The-Middle) attack to identify the encrypted text without the prefixes.

All this changes is in the "develop" branch, and will be merge and release few week later for v1.