Strong encryption of email should not be layered onto SMTP, but should use a new protocol designed for the purpose.
Simple Mail Transfer Protocol (SMTP) was defined in the early 1980s. At the time, there was no particular concern for security; the goal was to get email flowing among incompatible systems and networks. SMTP did a good job of solving that problem, and prevented the emergence of a commercial email monopoly.
It has been 25 years since the first attempt to make public-key encryption a standard part of SMTP email. The RFC for Privacy-Enhanced Messaging was published in 1993. Pretty Good Privacy (PGP), the first free public-key encryption software, appeared even earlier, in 1991.
And yet, encrypted email is still rare. For more than 25 years, programmers have tried the same approach over and over again: writing clients that layer PGP or S/MIME over SMTP-based email. This approach has found a rather small user base, and people who try it usually give up on getting others to use it.
In 1993, I was using Delphi dial-up on a DOS PC, and occasionally exchanging encrypted email with PGP 2.3a using the capture and send functions of the terminal program. That approach is ironically quite a bit more secure than most of what we’re using today. My project at the time was Secure Drive, the first open source full-disk encryption program for DOS. Later on I wrote Ad Extinguisher, the first open source web ad blocker for Windows.
Most people have apparently concluded that strongly encrypted email will never be the default. Recently arguments have been made that PGP is “dead” and needs to be replaced. Less secure approaches such as browser-encrypted webmail and passphrase-derived keys are being tried.
I disagree with this mindset. PGP works, and has proven its security against determined adversaries over the years. SMTP is the problem, not PGP. SMTP is broken as a secure email platform, and continuing to use it is wasting a large amount of money and effort. People are using the large webmail providers and file drop services precisely because SMTP is broken, but they are giving up security in the process.
The usual argument is that SMTP is the standard and is too entrenched to replace. This argument is wrong if you want encryption, for a very simple reason: encryption is not backward compatible with plaintext. You must have the encryption at both ends of the communication. Encrypted SMTP is no more compatible with plaintext SMTP than any other protocol would be. Therefore, if you want to add encryption, there is little additional cost in replacing the protocol. In fact, there may be a large savings.
SMTP is broken for secure email because:
1) The metadata is outside the encryption envelope. Mass surveillance gets the date, time, from address, to addresses, and subject of all encrypted SMTP messages. TLS only helps if you trust the service providers all along the route.
2) SMTP is vulnerable to spam. Spam filters use some combination of validating the sender IP address, and analyzing the content. If a message is encrypted, spam filters cannot analyze the content. Therefore, widespread use of SMTP encryption would make the spam problem worse, and would likely lead to the blocking of encrypted emails from other than trusted senders.
3) SMTP limits the message length to the 10-30 megabyte range. Larger files are transferred using file drop services. Unless the user knows how to manually encrypt them, such files are not secured.
4) SMTP does not handle key distribution. Another protocol is required. This leads to complex configuration of the client. If a new protocol is required to distribute keys, why not use it to distribute the messages as well, and avoid SMTP’s shortcomings?
Encryption of Instant Messaging has been more successful than encryption of email, because there was no one locked-in protocol that made encryption difficult. The curse of Instant Messaging is the lack of a single standard; the curse of email is the persistence of a bad one.
Encrypting SMTP has been tried, and has failed. It is time for a new round of innovation in email, and this will require a new protocol. Confidant Mail has the protocol features required to get that process started.