Secure communication with GnuPG and E-Mail

The first issue which hinders users from encrypting is that they need to exchange and verify keys before they can use GnuPG. The second issue is incompatibility between free E-Mail clients.

To protect the content of mails against breaking the main GnuPG keys we can realize Perfect Forward security for E-Mail by attaching a session key (the public key of a new keypair, signed by the main key of the sender) when sending an E-Mail to a given E-Mail address for the first time. When an E-Mail client receives such a session key and the signature is valid and from the sender, it should use that key as encryption key in subsequent answers - and attach its own session key.

Once the original sender switched to the session key of the original receiver, the communication can no longer be decrypted using only the main key of sender or receiver. Sender and receiver can save stored mail in re-encrypted form (with their main key) and refresh the session keys after a given number of mails were exchanged or after a given time (i.e. 100 mails or a month, what’s longer - always keep usability in mind!).

This means that mail which sender and receiver did not store will be safe from decryption even if the main key of sender or receiver is cracked at some point. Protecting E-Mails on the disks of the communication partners is outside the threat model here: If the E-Mail is sensitive, the communicatin partners can simply delete it to ensure that it is really gone once they delete the session keys.

Resilient Encryption: Perfect Forward Security

The most sensitive information which encrypted E-Mail still spills is the subject line. It provides the topic of the E-Mail and is sadly needed nowadays to protect against Spammers without trusting centralized services which cannot work for encrypted E-Mail.

To protect the subject line, we can follow the old Cypherpunk remailer protocol (example): Have an empty subject line, but start the encrypted content of the E-Mail with a new header field:

##
Subject: THE REAL SUBJECT

content to show the user follows here

(the cypherpunk protocol uses :: and ## as identifiers, and don’t know the exact semantic defference, so you might find that using :: to start the replacement headers might be more appropriate.)

Using an empty subject is already a widespread (bad-) practice, so it should not make the encrypted messages more tracable than before.

If users use no subject, the E-Mail clients should display the first 80 characters of the decrypted message in place of a subject. Yes, this only shows subjects after decrypting – which is how it should be.

Use an empty subject and redefine it in the encrypted part

To hide when a message is written, we can mask it under other traffic: using encrypted E-Mail for automated coordination of programs. We already send encrypted, signed E-Mails, and for each E-Mail address there is an accepted key. So we can now select trusted contacts whose messages our E-Mail program can interpret automatically, for example to set calendar entries or update the address book. We can implement social features subscribing to status updates (like twitter) or re-sharing articles over E-Mail, because signed and encrypted E-Mail provides a trusted channel without creating an opening for spammers and scammers: If there is one piece of software which has been battle tested by all kinds of malicious people then it’s GnuPG. Using E-Mail to convey information to be interpreted automatically is for example what Infocalypse uses to implement pull-requests over Freenet (E-Mail over Freenet provides additional protections compared to plain E-Mail – it hides metadata and content thanks to using Freenet as anonymous decentralized data storage and avoids spam via propagating trust and spam marking – so it can already implement this automated information channel without exposing its users to large scale exploits).

But while it would be wonderful to have fully automated social features over E-Mail, this is just a side product: The really important effect would be that there would be a constant flow of cover traffic which hides actual communication.

Mask “When”: Social features as cover traffic to mask date and time of real messages

The final piece to the metadata puzzle is the physical location from which we communicated. If people can see where we wrote from, we can never write from a smartphone without exposing more metadata than I dare to think about.

To hide our location, we need an anonymizing channel like hidden services on tor or i2p.

Mask “Where”: Connect to your E-Mail provider over hidden services

If you can get your friends to join, too, then E-Mail over Freenet would already provide this without making your E-Mail provider a target for anonymous cracking attacks.