Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My understanding (albeit limited) of asymmetric public key cryptography is that the public key is designed to be shared with one and all, while the private key is kept private.

Suppose I store my local machine's public key on a remote web server, and encrypted information (by my private key) I send to this server is intercepted by another party that also possesses my public key. Does this not mean they can also decrypt my encrypted information?

If yes, does this mean I should only share the public key with the one party - in this case the server - which goes against my understanding of what a public key is for? Can I have different key pairs on my local machine for different applications?

share|improve this question
up vote 6 down vote accepted

You don't send information to the server that's encrypted with your private key. When you open a secure connection with the server, the software on the server generates a new symmetric encryption key, encrypts it with your public key, and sends it to you. You then decrypt it with your private key and use that symmetric encryption key for the data you send to the server. Quite apart from the security aspects, public/private key encryption is too CPU intensive to use it on all data transfers -- it's only normally used for encrypting other encryption keys or for digital signatures.

share|improve this answer
Thank you Mike for an excellent answer. This makes complete and total sense, but unless I missed it the tutorials I read ommitted this point. – user101570 Nov 22 '11 at 18:28
yet, this does NOT saves you from man-in-the-middle knowing your public key and trying to mimic the server you are connecting to, that's why each time you connect to new host, ssh presents you the host fingerprint ans asks you to confirm that this is the host you intended to connect to. – Sandman4 Nov 22 '11 at 18:42

There are three very different things that you can do with a public key system:

  1. Send private data: for this, you don't use your public key, but the public key from your intended destination. Therefore, the data can only be decrypted using their private key.

  2. Sign public data: if you encrypt something with your private key, anybody (with your public key) can decrypt and read it, but then they know that it's you who wrote it, and that it wasn't modified. In practice, the whole message isn't encrypted, only a checksum that's used as a signature.

  3. Establish a private channel: this is more complex, the most common method is the Diffie-Hellman key exchange protocol. This short interchange allows two parties to generate a common secret, and even if somebody intercepted the communications, he won't get that shared secret if he didn't have one of the private keys. Then, the shared secret is used to encrypt the rest of the communications.

I think you've read descriptions of the first two cases, but your question (and Mike Scott's answer) seemed to be about the third.

share|improve this answer

with the public key you could encrypte and send to the holder of the privte key to decryped, you cann't decrype with the public key.

you could have many different key pairs on one machine.

share|improve this answer

The only use SSH makes of the public key is to determine the identity of the holder of the corresponding private key. About the only think you can do with an SSH public key is determine whether or not a cooperating authentication agent holds the corresponding private key.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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