If you are familiar with basic cryptography such as key negotiation, certificate distribution and the differences between symmetric and asymmetric crypto, you can skip ahead to the next section.
For those who want to freshen up, keep reading below. What follows is a very brief and sometimes a bit simplified introduction to essential cryptography. For further reading, we recommend Bruce Schneier's indroductionary book "Applied Cryptography".
plaintext - the message in unencrypted form
ciphertext - the message in encrypted form
In symmetric cryptography, such as AES or Salsa20, both the sender and receiver use the same key. A famous simple example of this is the Caesar cipher where you produce a ciphertext by shifting every letter in the plaintext by a fixed number of steps in the alphabet. The secret key is then the number of steps shifted.
Key = 2 => HELLO -> JGNNQ
The most important take away here is that the sender and receiver uses the same key. Therefore, they both have to agree to a key before they can exchange information.
Modern symmetric crypto algorithms are highly secure and efficient, but the sender and receiver using the same key can be troublesome.
Asymmetric cryptography however does not require the communicating parties to agree to a shared key beforehand. This is because in asymmetric cryptography, each endpoint has a key-pair instead of a shared key. The key-pair consists of a public key, used for encryption, and a private key, used for decryption. As the names imply, the private key is secret and should only be known to the owner, while the public key is public information.
The endpoints in an asymmetric system, let's call them Alice and Bob for convention, register their public keys at a common key server. If Alice wants to send a message to Bob, she grabs Bobs public key from the key server and uses it to encrypt a message for Bob. Bob can then use his private key to decrypt the message.
Asymmetric crypto is however more demanding for the cpu and requires longer keys.
Using asymmetric cryptography, we can let people send us encrypted messages without a prior relationship to them. A fantastic advancement!
But how does Alice know if she actually has Bobs key, or if someone has given her a faux key? Have the wrong public key is not only a matter of being able to encrypt for Bob, we are also wary of Mallory. Mallory is a malicious user who wants to intercept the communication between Alice and Bob. Therefore, Mallory gives her own public key to Alice, telling her it is Bobs Key.
To avoid this, we can use a Trusted Third Party. The trusted third party is basically a key-pair which everybody trusts. The trusted third party uses its key-pair to perform a digital signature on end users public keys, which it makes public. Since everybody knowns the public key of the trusted third party, and also trusts it to act correctly, they can now trust that they have obtained a correct key and only the intended recipient will be able to decrypt it.