The problem with GPG is one of key management. The first person who truly solves that well (both reasonably secure and reasonably easy) is going to do well. To date, everybody has failed.
(Disclaimer: I am working on solving that and hope we can make it work. :)
Another problem with using PGP to encrypt mail is that it only secures the message body. It doesn't secure the subject line or other headers. If I send a PGP encrypted email to somebody, their email provider can't read the message body, but what they do know is the email address of the sender, when they sent it, and when it was picked up.
If everybody in the World started using PGP to encrypt all email tomorrow, we'd still have massive privacy problems that need addressing.
P.S. I use PGP extensively. I sign all of my emails and even my HN profile, and encrypt whenever I can.
If you are providing a communication routing service, you MUST have information about sender* and recipient. That is not a problem with PGP encryption, it is a problem with people who wish to use public routing services like Gmail.
Furthermore, since the internet is also a public communication routing service itself, there is a tradeoff between information leaked to the email provider, and information leaked to the ISP. Using a smaller email routing service implicitly gives the ISP more specificity, and using a large one gives the email provider more specificity.
Since it is, in general, harder to access an ISP anonymously than it is to access an email provider anonymously, the current state of using large email services is in many ways superior from a privacy perspective.
* sender if you want ACK, and recipient so you can deliver the message
Assume I'm mike@example.com and I'm sending a message to dave@example.org.
"sender if you want ACK"
The example.org service doesn't need to know the sender address. It only needs to know a method for prompting the sending server to send an ack to whoever the sender of the incoming message was.
"recipient so you can deliver the message"
My own mail service only needs to know that I'm sending a message to somebody at some domain managed by the example.com server. It doesn't need to know that I'm sending it to dave@example.com.
A better mail system (from a privacy perspective) would be one where the routing logic was handled by the email client first, and the outgoing mail server was just a dumb queue. Imagine I'm sending the email to dave@example.org:
My email client encrypts the message body, subject line and sender address with dave@example.orgs public key.
It then looks up the IPs of the MXs, and their public keys.
It then adds the recipient address (encrypted with those public keys) to the message. It then connects to my outgoing mail relay, tells it the list of IPs to try, and passes the encrypted message on.
When the message is passed on from example.com's servers to example.org's, they can decrypt the recipient address and pass on the message to that recipient.
dave@example.org can decrypt the message and sender address after downloading it.
If you want to retain the "bounce" capability rather than example.org just refusing the message at SMTP time, example.com could pass a unique identifier with the message when it sends it to example.org. Then example.org can just send the bounce back with that unique identifier, and example.com can then map that unique identifier to the original sender.
(Disclaimer: I am working on solving that and hope we can make it work. :)
reply