Securing A Chat Application

Question

I am working to make a secure chat application for Windows Phone 8.

I am planning to use ASMX SOAP Services and I have decided to use Public Key Encryption technique to encrypt data but i am very new to network security.

My approach is :

1. As soon as the user signs up, a public/private key pair is generated at the server.
2. The public key is then sent back to the phone app client and all the data that will be sent from the client to the server will be encrypted by the public key on the client and decrypted by private key on the server.

Now what I want to know is that for the responses that the server will send to the client, how will those be encrypted and decrypted?

If the private key on the server is used to encrypt the responses, then it can be decrypted by anyone as the "public" key is public.

Do this means that I have to generate two public-private key pairs, one generation on server and one generation on client.

One pair will encrypt and decrypt data that is sent to the server and other pair(generated at client) will be doing the same thing when data is sent from the server in response.

Answer 1

If you are concerned about messages being intercepted "in flight*, I suggest you put your API on a HTTPS server. That way everything is encoded.

HTTPS does something very similar to what you describe, except it happens behind the scenes and your application doesn't need to know anything about it.

Hypertext Transfer Protocol Secure (HTTPS) is a communications protocol for secure communication over a computer network, with especially wide deployment on the Internet. Technically, it is not a protocol in and of itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications. The main motivation for HTTPS is to prevent wiretapping and man-in-the-middle attacks.

more info

Answer 2

Yes, you can generate a key pair on the client, and send the client's public key to the server. But if you use public key encryption to encrypt messages you are (a) limited to small messages -- a 1024 bit RSA key encrypts less than 128 bytes, and (b) going to pay in performance because public key encryption is much more costly than symmetric key encryption, such as AES encryption.

Now that you have a way to secretly send something from the client to the server, by encrypting with the server's public key, you can generate a random symmetric key on the client, and send that to the server, secretly. Now both sides have a symmetric key, which can encrypt much, much larger messages, and is much more efficient, especially on a phone.

Look into AES, for example, and authenticated encryption modes where the messages are not only secret, but tamper-proof.

You have the problem that somebody can easily impersonate the client, once they've seen the server public key, but that's a risk of implementing your own crypto. :^) Outside of a college project, where you are asked not to use SSL, you should not implement your own crypto.