When you receive a public key, from any source, unless it is handed to you directly by the owner of the key, it could have been altered. This alteration, while difficult to detect, could be disastrous for security. To illustrate this, let's consider the example of Alice and Bob, two people who wish to send secure email between each other. We will also discuss Mark, a malicious eavesdropper who wants to know everything between them, and possibly change it.
Alice and Bob want to be able to send secure email back and forth to each other. They exchange public keys, and begin sending email back and forth, thinking that their messages are totally private, and can not be read by anybody else.
However, when Alice sent her public key to Bob, it passed through Mark's computer. He intercepted the key, and created a new public key in Alice's name. He did the same for Bob when Bob's public key passed through his computer. Now, email messages go through his computer, addressed to Bob. These email messages are automatically decrypted (using the false keys for Bob), their readable information stored away, and then re-encrypted using the real keys for Bob and sent on. The same happens with email from Bob to Alice.
All of their conversations are open to Mark because of a simple security issue.
Fortunately, there is a way to resolve this issue. We do three things with each key we receive to help us verify the identities of everybody involved, and prevent key fraud.
We'll go through each of them in order, and describe what each part is, and how to use it to improve things.