I have the public key of the receiver, and the private key of the sender. I want to generate a new key by using the receivers public key and senders private key (also known as the signing key) to encrypt a file for this process i.e. utilizing both of the keys at the same time know as a shared secret key.

Could you please tell me how I should generate a shared secret using an existing receivers public key and senders private key?

  • Are you looking to protect data in motion or data at rest? That is, SL Barth's answer protects data in motion, although it arrives in the clear. Do you want the message to be protected when stored and also have other characteristics of message protection like signatures, encryption and non-repudiation? Dec 7, 2015 at 18:41

2 Answers 2


You don't need to do this; this is already solved by the SSL/TLS handshake.

The SSL/TLS handshake goes a bit further, in that it not only establishes a secret by using both the public and private keys of both parties, but also uses a certificate to establish that the server is who it reports to be - preventing a man-in-the-middle attack.

A quick, more detailed description of the steps involved is here.

But since you tagged the question with "HTTP", I assume you want to send the file via HTTP. Just using HTTPS means you're already using SSL or TLS for key exchange, negotiation of a secret key, and usage of that secret key for encrypting the file while it is in transit. And some protection against MITM in the process.

  • Look for the cipher suite dhe+RSA for network security. Dec 7, 2015 at 18:39

Not sure what your use case is here. If you're just encrypting a file so that your partner can read it and nobody else, and don't care about authentication, replay, or MitM, and you are completely confident in the process that you and your partner use to exchange public keys, then you can use a very simple procedure.

  1. Generate a symmetric key using an algorithm of your preference.
  2. Encrypt the file with the symmetric key
  3. Encrypt the symmetric key with the receiver's public key
  4. Send 2 and 3 to your partner.

I am not sure why you want to include your own private key in the process. As long as the receiver can decrypt the key (and he can, because you used his public key) then the secret is already "shared" because you generated it so you obviously know it.

Only thing I can think of is maybe you want the receiver to be certain that the file came from you and from nobody else. In that case, I suppose you could

  1. Take a hash of the whole mess
  2. Encrypt the hash with your private key
  3. Send the result of 6 along with 2 and 3

...assuming the receiver has a way to be confident that he has a correct copy of your public key (which is not necessarily trivial).

If you are not completely confident in the process that you and your partner use to exchange public keys, then you will need to leverage a PKI infrastructure, or switch to a simpler scheme such as a shared secret with out of band exchange.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .