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, , 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. .
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:
: 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)).
: 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.