Creation of an Encrypted Chat Client

[bloggeroliver]

Hello!

 

I am working on writing a chat client in C#, which functions over a server with PHP scripts and a MySQL database and over this exchanges the messages of the users. The client should be relatively safe.

The program and source code is available on http://csharp-tricks-en.blogspot.de/p/c-crypto-chat.html, I would be happy if someone checks it out.

 

But especially I here want to discuss the security of the chat.

The basic idea is the following (I would like to not use TLS, so that the client is easily and universably usable - also on free hosting spaces etc):

 

When creating a new user an RSA key pair is created, the private key is encrypted via AES and stored on the local PC, the public one is entered in the server database.

Login is done via a Challenge Response Authentication, the server creates some random string and encrypts this with the public key, the client then decrypts this.

If one now wants to send a message to a different user, the client now queries the server for the public key of the server, with which the client then encrypts the message, the receiver decrypts it. The server uses PHP sessions to make sure that only authenticated users can read and send messages.

 

So with the encryption now is assured that only the correct receivers can read their messages.

I see the following attacking possibilites:

 

1. Requests from the clients like fetch messages of user X or send a message as user X can simply be replayed, so someone could misuse the session of user X.

Solution: The client signs every request with his private key, the server checks this.

 

2. When querying the server for public keys of users a man in the middle could intercept and change these. Solution: The server encrypts its answer with a public key of the user. (Or better: The server also gets a key pair and signs its answer?)

 

But except for that, I right now don't see any problems. What do you think?

 

I would be very happy about answers, best

Oliver

[Lant]

Is this over a single server? If so that is going to be vulnerable to DDoS attacks, so a service like CloudFlare might be useful.

 

If there is a way to eliminate the central server(s) completely, that would be even better.

Where is the private key created? It should only be created on the client and never on the server, the private key should never be sent over the wire. What length keys are you using?

How is the private key stored? It might be worth encrypting it with a password.

Can other programs access and modify the private key? The file permissions might be worth looking into.

 

It does sort of seem that this already exists with tools like OpenPGP/GnuPGP and email.

 

Having the code on github/bitbucket would make for easier auditing.

[bloggeroliver]

Hey Lant,

 

thanks for your quick answer!

 

Yes it is a single server, I first concentrated on the goals integrity and confidentiality.

 

The private keys are created on the clients, the local computers and never leave it. I know that that a size of at least 2048 should be used, but I did not touch the length yet because this can be changed quickly. The private key is encoded via AES (for which a password is chosen by the user) and stored on the local computer in a simple file. What does it matter whether other programs have access to the key and can I even prohibit that?

 

And yes true it's kind of like PGP, just that I wanted to create a chat client.

 

Further, I am more concerned right now about the communication between server and client and am wondering if the steps described above for securing that are enough.

 

And I'll put it on github soon.

 

Thanks!

[bloggeroliver]

It is now online on GitHub, see https://github.com/bloggeroliver/CryptoChat.git.

 

Greetings,

Oliver

[+theblazingangel MVC]

Further, I am more concerned right now about the communication between server and client and am wondering if the steps described above for securing that are enough.

 

No. There is no absolute guarantee that client-server communications to exchange public keys will not be compromised with a MITM attack. HTTPS will help, but should by no means be considered a guarantee of security to your users. The ONLY way for your users to be certain that key exchange has not been compromised is to undertake the usual in-person/over-the-phone fingerprint checking.

 

You describe using the public-private keys for encryption of every message. Understand that a web browser uses public-private key cryptography in an SSL/TLS connection only for setting up the initial connection. Symmetric (AES) encryption keys are generated and exchanged during this setup phase and used afterwards for exchanging actual data. One reason for this is that symmetric encryption is more efficient, thus reducing load on server and client.

 

Also, I believe I am right in saying this, the more data encrypted with the same key, the easier it is to crack that key. Following the web browser example and generating symmetric keys for message exchange, and replacing them every so often, may be a more secure design.

[Ambroos]

Not using TLS is a huge downside.

 

Security is a hard thing. It's not very wise to reinvent the wheel when you can just set up a server with TLS, configure it to only accept encryption with perfect forward secrecy and you've got your client-server encryption problem solved. Then you can use whatever method you want to authenticate users.

 

Whatever you end up doing, you'll probably simply result in recreating something that already exists security-wise.

[+Warwagon MVC]

Not using TLS is a huge downside.

 

Security is a hard thing. It's not very wise to reinvent the wheel when you can just set up a server with TLS, configure it to only accept encryption with perfect forward secrecy and you've got your client-server encryption problem solved. Then you can use whatever method you want to authenticate users.

 

Whatever you end up doing, you'll probably simply result in recreating something that already exists security-wise.

 

Then he needs to show your source code to some cryptographers.