Multiple Asymmetric key pairs for one user?

Question

I'm creating an Android application, that at first needed to be able to transmit data to the server securely. So I thought of RSA.

I would send the public key to the user, let him do what he must, then receive back and decrypt via private. That is all fine.

But now it seems, that there should also be some sort of encryption to the other side. Meaning, there should be means of encrypting a message and sending it to the user, and allow only the specific user be able to read it.

This smells like having 2 pairs of keys, and sending public key from one pair and private key from the other to the user, and keeping the rest to the server.

I have looked at symmetric keys, but they somehow seem less secure to me.

Am I missing something, or is this common? I'm somewhat new to the whole cryptography scene.

Answer 1

The usual advice applies: use HTTPS, don't try to invent a secure messaging protocol. You will most likely fail. If you absolutely need to this, the usual way is to use RSA keys to encrypt symmetric session keys and encrypt your data with those. Also note that the size of data you can encrypt with an RSA key is limited by the key size (1024, 2048, etc. bits).For two way communication, each party needs to have the other party's public key. So it goes something like this:

1. Alice hands her public key (RSA) securely to Bob (see below)
2. Bob hand his public key (RSA) securely to Alice
3. When Bob wants to communicate with Alice, he generates a session key (say, a 256-bit AES key), then uses her public key to encrypt it.
4. Bob sends the encrypted session key to Alice.
5. Bob uses the session key (AES) to encrypt the message, and sends it to Alice.
6. Alice uses her private key (RSA) to decrypt the session key (AES).
7. Alice decrypts the message from Bob using the session key (AES).

Reverse the roles of Alice in Bob in steps 3 to 7 for communicating the other way.

But of course, if you send a public key to someone, how can they be sure that it is actually your key, not mine? If you don't hand it in person and show your photo ID, this is far from trivial.

Then, you need some way to verify that the (encrypted) message from Bob has not been modified (you can cut in half, and it will still be valid and decryptable; there are other, more sophisticated attacks, of course).

So just convince whoever you need to convince to use HTTPS or some other established protocol, and don't try to re-invent the wheel.

Answer 2

This smells like having 2 pairs of keys, and sending public key from one pair and private key from the other to the user, and keeping the rest to the server.

This is not how public key infrastructure works. Each of you generate your own keypairs, and exchange public keys.

Server's public key is used by client to encrypt data to server and verify signatures on messages received from server.

Server's private key is used by the server to decrypt messages from the client and to sign messages going to the client.

The reverse actions for the client's keypair are the same.