Month: September 2013

Many secure email systems have all shuttered , because they were compelled by courts to invalidate their security or feared that possibility.

Here are two popular models and weaknesses :

1. *Send/Receive unencrypted email , encrypt on server.* This is what Lavabit did. The weakness is that the government is able to compel the provider to copy/clone/divert the unencrypted mail.

2. *Web based mail, encrypted in browser.* Hushmail did this. Their weakness is that the government is able to compel them to deliver a compromised applet/library onto the client side browsers.

In order for email to be reasonably secure, it requires a few key components:

1. *End-to-End Encryption.* Data must be encrypted by the Sender and decrypted by the receiver. Service providers should never be able to access a plaintext version or have the means to decrypt a message.
2. *Full Transparency of Code.* Email clients must publish their source code and libraries, so that any sort of backdoors can be identified. Without open-source and full transparency, Service Providers and Software Vendors can be compelled by courts to offer insecure products.
3. *Required Encryption.* Plaintext emails should not be deliverable at all. This would force widespread adoption of secure email , and keep ‘snoopable’ email off of email servers.

In order to achieve this , I suggest the start of novel improvements to current email as follows:

1. All emails should be encrypted via public-key cryptography within the email client.
– Outbound email is encrypted for the Recipient
– Drafts are encrypted for the Sender
– An email header contains a digest of the key used for encryption
2. SMTP should be extended with new commands and responses ( SSMTP ). Generally speaking :
– SMTP servers should reject unencrypted email
– SMTP servers should reject email with an unknown or expired Public Key

It would be trivial to extend a SMTP server like Exim with those requests. Many mail servers easily connect to SQL or LDAP backends to find delivery information; extending this information with a list of VALID and INVALID public keys for each user is trivial.

A current SMTP example looks like this ( from http://en.wikipedia.org/wiki/SMTP )

2- A new Mail format might be needed. Currently, email headers contain a lot of sender/recipient information — as well as the subject lines. In order to be fully secure, the Subject line needs to move into the encrypted payload. Other headers would need to either move or be stripped. at the least, something like this should exist.

3- The distribution of Public Keys is troublesome. At first I thought servers could advertise public keys as a directory service, and delivery failures could contain a “New Key” attachment. However, this creates a potential for a man-in-the-middle attack. For example, the NSA could compel an ISP to work with them by advertising an NSA key , decrypting and storing the message, then re-encoding the message with the proper key. It would be possible to identify this with Message Signing , but one or more messages would have been stolen.

Nevertheless, a secure method of distributing and verifying public keys would be needed.

There are complications and weaknesses in this approach, but I feel they are significantly smaller than other approaches I’ve seen lately.

In any event, I don’t think it’s possible to make the current SMTP system reasonably secure — I believe we need to change/extend it.