Should the client or the server generate the client's public-private key pair?

Question

Say I have a mobile messaging app. There is a central server that manages stuff (like a directory of users, onboarding, etc.) and there are all the clients.

My app is professional, so it uses asymmetric encryption to securely send messages.

My question is, in short, should the client or the server generate the public-private key pair?

If the client generates the pair, then the pair can be generated on the client-side and then sent to the server (maybe encrypted with the server's public key).

If the server generates the pair, then I had a more complicated idea:

1. Client generates secret (S)
2. Client encrypts secret with server's public key
3. Client sends encrypted secret to server
4. Server decrypts encrypted secret with server's private key
5. Server generates public-private key pair for client
6. Server encrypts private key with secret (S) and removes it from memory
7. Server sends encrypted private key to server
8. Client decrypts encrypted private key with secret (S), which it had from the beginning
9. Hooray! Client now has private key and public key is on server!!! :)

So, which approach is better--should the client or the server generate the public-private key pair from a security perspective? Is there a better/more efficient/more secure way to do it than my solutions?

Answer 1

My question is, in short, should the client or the server generate the public-private key pair?

In theory, the client should generate their own key pair. That way the private key:

• is known only to the client
• is not exposed to transfer

In practice, it's not unheard of to see servers generating client keys and handing them out. However, this is usually only done in cases where the client lacks some necessary resource which can generate a key and a CSR themselves:

• limited processor
• human interaction required

(Quite literally, most "server hands out the keys" setups I've seen boil down to "our users are too stupid, and our support group doesn't want to hand-hold them all")

It sounds like you're implementing server and clients. If you have that level of control, then generate client keys at the client because it's the right thing to do.

Answer 2

should the client or the server generate the public-private key pair?

I think that depends what your design goal is:

If you want communication to be totally secure and only decryptable by the sender and receiver, then keys should be generated on, and never leave, the client. If the client is a Android or iOS app, then look into the Android Keystore or Apple Secure Enclave so that the client's keys are created in a separate processor and not even accessible to the app -- let alone the server.

If you want the server to be able to read / archive / log / modify / wtv the messages, then the server needs a copy of all the private keys (or a protocol where each client encrypts for the server's keypair). At that point you give up all pretenses of privacy though.

---

The method you have described where one party generates the key and sends it to the other is a well-used scheme. In fact, that's exactly how the RSA key establishment mode of TLS works where the client sends up a premaster secret to the server from which the session key is derived (slide borrowed from a Royal Holloway University of London summer school talk).