Consider the private key and actual key, and the public key a padlock. Whoever you hand over the padlock can close something (for example, a vault containing the secret message), and only you (keeping the private key safe) can open it again.

And remember the padlock is digital: it is easy to replicate it an unlimited number of times. In fact, you often share it in some public directory to everybody who wants to have it.

My "basic" understanding is that I can generate the public and private keys, encode the file using the public key and our partner can decrypt using the private key we give them. But this sounds a bit strange to me that we would be sharing the private key. There is just one trusted partner.

It's the other way round: The recipient generates the key pair, and passes the public key ("padlock") to you. Now, only the recipient can decrypt the message, as he's the only one holding the private key.

Additionally, you don't have to care on a man in the middle getting hold of the private key -- and if he intercepts the public key, he still cannot read messages. Just make sure to verify the fingerprint after receiving the public key (for example by phone), to make sure the public key was not replaced during transmission.

Additionally to encryption, you can also *sign* messages, so the other party can *verify* the sender. In this case, also you would generate a public/private key pair. Signing pretty much works the other way round (the analogy with the padlock doesn't work out any more for signing), consider it encryption with the private key (which only you can do, as it is kept secret). If the recipient can decrypt the message (or usually, a hash sum of the message) using your public key, he knows it must have been you that signed the message.

2more comments