2

I have created a chat between two parties (using c#), and I am wondering what kind of weaknesses have I overlooked.

Description of its functionality: There are two individual applications: Client (2 instances of TcpClient being the communicating parties) and Server (TcpListener, the relayer of encrypted messages).

Note: I am assuming that both computers containing the client application are safe and don't contain any malware or viruses that could tamper/monitor memory, input keys, make screenshots, etc... On the other hand the Server application can be on any computer which can be potentially 'compromised' for lack of a better term.

Now Clients's functionality is registering the message from the keyboard of the user, encrypting it (Using AES256 c# classes) and sending the data to the server. Although before the messages could be sent the clients are exchanging public keys according to Diffie Hellman key-exchange algorithm, but all the communication between the clients works through the server. Essentially the server is a gateway, a bridge between the clients, [1], after key exchange and secret key generation server only receives encrypted messages, it doesn't bother with its contents, just relays the message to the other client, which decrypts it locally. [2].

I have been thinking to wrap my NetworkStream into an SslStream, to make the communication channel more secure, but even if someone can 'read' the stream they can not read the encryption anyway, so I don't think this is a critical flaw for keeping the SECRET-MESSAGE safe.

I am not protecting my .exe file in any way (neither in server nor in clients) since I do not think there is a 100% protection if the computer has already been compromised. In other words the bad guy can decompile my .exe, how bad is this and should I even take some kind of precautions? Although the secret keys generated by D-H are kept locally in computers (generated anew every time a connection has been established between clients) since I am assuming that the Client computer is safe, there shouldn't be any problems with this, right?

Weaknesses I've noticed:

[1]: It has a direct access to clients information (IP address, when was the message sent, even how many characters the message contained (~ of 8 bytes)).

[2]: The server application can be tempered with, to imitate the second client and capture the channel, sending their own public key and receiving other client's public key, effectively taking the place of second client. This can be easily solved if the parties exchange a greeting in any other communication software (skype, etc) and confirm that they are connected to each other (messages are being received at the same time they are sent, etc).

P.S. I am aware of some weaknesses that I have mentioned above, but those aren't critical, I would like to know are there any critical flaws that I have missed, and how would you rate this setup from 0-10? What can I add/change make improvements to what I already have / fix flaws.

Benoit Esnard
  • 13,979
  • 7
  • 65
  • 65
Arman Papikyan
  • 23
  • 2

2 Answers2

2

This communication protocol is fairly weak as you do not provide authenticity or integrity. There are a number of attacks it is vulnerable to. The most severe ones I can think of based on what you said are:

  • Replay attack - A replay attack involves an attacker sending a copy of any part of encrypted data. The recipient will not be aware that the message is a replay of a previous message. The attacker does not need to know the contents of the message to pull off this attack.

  • Malleability attack - You didn't mention what mode of operation you were using. Assuming it is CTR or CBC, an attacker will be able to modify the ciphertext to change the plaintext in predictable ways. The only solution to this is to use an integrity construct such as an HMAC.

  • Man-in-the-middle attack - An MITM attack is possible as Diffie-Hellman is unauthenticated. To provide authentication, you would need to use an additional keypair such as RSA or DSA. The DH key exchange must be signed by these keys in order to ensure authenticity. The fingerprints of the private signing keys can be exchanged separately, or exchanged and stored so all subsequent connections are using it (a technique called TOFU, or Trust-On-First-Use).

  • Semantic insecurity - If you are using ECB mode (or incorrectly using CBC mode, or a mode not designed for this purpose such as XTS), encryptions of the same plaintext has the potential to result in leaking information through duplications visible in the ciphertext.

  • Metadata leakage - The length of messages of text gives away a surprising amount of valuable information. Unless you are padding your messages to a specific length, or at least padding them up to a multiple, you are allowing an attacker to learn information about the conversation based on the length of the ciphertext. Padding in this context is unrelated to padding in cryptography.

As you can see, there are a lot of variables that come into play when writing a cryptosystem. Real cryptographic protocols are quite complex. This complexity is absolutely necessary for mitigating a variety of common and not-so-common attacks. As you asked for a 0-10 rating scale, I would give this protocol around a 3. If you use ECB mode or you generate AES keys improperly (e.g. using a poor PRNG), it would be even lower. If you want to write an application that does encrypted chat, I would suggest using the OTR library, called libotr. The library provides secure end-to-end encrypted communication and repudiation (plausible deniability in regards to message contents), and more.

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
forest
  • 65,613
  • 20
  • 208
  • 262
-1

Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack.

This is why shared secret should be verified in-person if possible or through another communication channel (less secure).

Jonathan Cross
  • 1,618
  • 1
  • 13
  • 25