Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potentially Risky Representation of Encrypted Messages #21

Open
H-MAli opened this issue Apr 25, 2024 · 1 comment
Open

Potentially Risky Representation of Encrypted Messages #21

H-MAli opened this issue Apr 25, 2024 · 1 comment
Labels
enhancement New feature or request security

Comments

@H-MAli
Copy link

H-MAli commented Apr 25, 2024

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 mostafa-kheibary added enhancement New feature or request security labels Apr 25, 2024
@mostafa-kheibary
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request security
Projects
None yet
Development

No branches or pull requests

2 participants