"They are reading your email because you are not encrypting it."
One of the problems we have here is that tools like PGP and S/MIME require the receiver to do something before the sender can encrypt a message for them. We need something like identity based encryption, where the sender decides if the message will be encrypted and the receiver does not need to publish anything in advance (threshold IBE systems should probably be used to ensure that no single entity can read everyone's mail). Unfortunately, IBE and related technologies are thoroughly patent-encumbered, and so it will be a long time before we can just deploy it freely.
I'd prefer if people encrypted email before sending it to me, but most don't. So my email server encrypts it with my public key on the way in. This is obviously not as good, but it provides several benefits.
First of all, if you gain access to my email account, you can't read my email because you don't have my PGP key. So for example, even if you trigger a password reset email for any of my other online accounts, you wont be able to access the confirmation link/code contained within in order to take over those accounts too.
Secondly, the mail store on my server and all of my email clients, eg inside K-9 mail on my phone/tablet and Evolution on my laptop are all encrypted. So if you compromise/steal any of those devices, you don't automatically get direct access to all of my mail.
Thirdly, it means I use PGP every day, so I become more familiar with the way it works and how to use it over time. I tried using PGP in the past but ended up forgetting how to use it properly because people rarely sent encrypted mail to me.
How awesome would it be if we woke up tomorrow and Google had added a section to their GMail settings page where you could upload your public PGP key and it would automatically encrypt all of your incoming mail with it? Especially if they released an addon for Chrome which allowed you to safely use PGP within the GMail web interface.
You need to exchange key's before you can encrypt a message.
Think of it like this in a pure one way communication you send all parts of the message, and anyone who reads it can decode it. If you instead get one of there key's (even if it's from a 3rd party) you can encrypt something for them. Or you can think of it like this, if the receiver never makes any key's there is nothing special about them that prevents others from reading there messages.
In identity based encryption, there is a key generator that gives out secret keys, and a master public key that the sender needs for encryption. To encrypt a message, the master public key and the receiver's "identity" (e.g. email address) are used. Thus the sender and the receiver do not need to exchange keys in advance; the receiver must get their decryption key from the key generator, but there is no need to do so before the message was actually encrypted.
The key generator can decrypt any message, of course. That is why I said threshold systems should be used, so that no single party is the key generator. In that model, the receiver would have to request that several parties jointly compute and issue the decryption key. It is also reasonable to imagine a world where there are many IBE authorities, and the sender of the message can choose which IBE authority the receiver will have to get their keys from.
Think it through, your treating public information as a private key which is hardly secure. You could also use the users email address as the seed for a random number generator which would spit out keys and not involve 3rd party's but that's also unsafe.
After all, what tells the Key Generator that bob@bob.com is actually bob@bob.com and not Alice?
I did. Look at the picture provided it's the authenticate step that's the problem. Alice wants to send Bob a message. Alice contacts public key authority and says give me bob@bob.com's private key, encrypts the message and sends it. So far so good.
Now, someone contacts the key authority and says I am Bob@Bob.com what's my private key. Without prior communication between Bob and the key authority there is no way to do that exchange over an open channel securely. Assuming email addresses are public information and someone can get bob's email address before he communicates with the key authority.
Err, I did. Look at the picture provided it's the authenticate step that's the problem. Alice wants to send Bob a message. Alice contacts public key authority and says give me bob@bob.com's public key, encrypts the message and sends it. So far so good.
One of the problems we have here is that tools like PGP and S/MIME require the receiver to do something before the sender can encrypt a message for them. We need something like identity based encryption, where the sender decides if the message will be encrypted and the receiver does not need to publish anything in advance (threshold IBE systems should probably be used to ensure that no single entity can read everyone's mail). Unfortunately, IBE and related technologies are thoroughly patent-encumbered, and so it will be a long time before we can just deploy it freely.