I have a client side android app which needs to send an encrypted string to a server implemented in PHP. For this I have chosen an asymmetric algorithm (RSA).

Should I:

  • Save a public key in client side and use this for encryption and then send the private key and encrypted string to the backend


  • Get the public key from backend first and then do the encryption and then send the encrypted string only to the backend

If neither one is enough good, can anyone suggest the most followed practice?

  • 2
    You never, ever, absolutely never, send a private key. That's what "private" means.
    – gnasher729
    Commented Dec 1, 2017 at 20:06
  • @gnasher729 suppose if iam sending some set of encrypted params(say for example in a banking application), is it enough to setup a HTTPS connection and not use any other sort of encryption? Commented Dec 2, 2017 at 4:30

1 Answer 1


Implementing your own crypto is likely to be error prone, so please don't do that.

If you are trying to encrypt data in transit between your app and your backend (i.e. provide confidentiality for that transmission), then using a HTTPS connection is likely to be entirely sufficient. Both the app and the server will then see the unencrypted message.

Note that all certificate authorities trusted by the device running the app can issue certificates for your site. This is frequently used in business networks to intercept any encrypted traffic, but is generally done with the knowledge of the end user. You can prevent this if the app pins the correct certificate, but that may break the app if you need to change the certificate on the server. This is not something you should generally do, but it is important to be aware of the limitations of HTTPS in case you are dealing with highly sensitive data: HTTPS provides confidentiality but not necessarily authentication.

HTTPS works roughly like your second example. The server provides a public key. This key is signed by a certificate authority (CA). The CA is supposed to verify that this public key belongs to the domain you are connecting to. The key is accepted when the end user device trusts the signing CA. Now the client can send messages to the server using the server's public key, and only the server is able to decode this message. That is used to negotiate a short-lived symmetric session key which allows for more efficient communication. Now that the secret session key has been exchanged, the server and client can talk to each other over an encrypted channel.

A private key should never be transmitted. The whole point of public/private cryptography is that you do not have to share a secret key in order to decrypt messages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.