Secure communication with GnuPG and E-Mail

How E-Mail with GnuPG could hide when you talk, where you talk from and what you talk about.

or in technical terms:

E-Mail with perfect forward security, hidden subject and masked date using GnuPG and better frontends.

Update 2018: Some of these ideas are becoming real and widespread now with pΞp (pretty-easy-privacy) and the autocrypt-standard.

If you regularly read my articles, you’ll know that I’m a proponent of connecting over Freenet to regain confidential and pseudonymous communication.

Here I want to show how it would be possible to use E-Mail with GnuPG to get close to the confidentiality of Freenet friend-to-friend communication, because we have the tech (among the most heavily scrutinized and well-tested technology we use today) and we have the infrastructure. All it requires are more intelligent E-Mail clients. Better UI which makes the right thing easy.

Why isn’t encrypted E-Mail confidential?

What is that wretched metadata?

Sending an encrypted E-Mail currently levaes all kinds os non-encrypted public traces, while it travels over the servers:

  • When you wrote (date)
  • What you wrote about (subject)
  • Who you wrote to (sender + receiver)
  • Where you wrote from (via your IP)

Also there is no perfect forward security (PFS), so all your past E-Mail can be decrypted when someone one day manages to crack your key or the key of the person you talk to.

It might take a few weeks or months, but if at one point you become important, people in power will crack your key – maybe by simply hacking (or confiscating) your laptop.

And then they can read all E-Mails you received with it. Even if you deleted them, because they likely still have a copy.

Crack once, read everything

And finally, almost no one uses GnuPG, because (for one thing) key verification is cumbersome and E-Mail clients make it hard to use. But on the upside, all these issues can be solved without touching a line of GnuPG code. All you need to fix are the clients.

Regaining confidential communication with E-Mail

To make E-Mail confidential with GnuPG, there are 5 challenges to overcome:

  • Make GnuPG effortless to use (no setup for the user!)
  • Ensure that most encrypted content stays encrypted after security breaches
  • Protect the subject line
  • Mask the date and time of communication
  • Mask the physical location

I’ll go through them all with short notes how they can be realized. None of these requires experimental concepts, since most of the ideas have been known for years. They just weren’t collected and implemented.

Effortless GnuPG

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.

Eradicating the requirement to verify all keys

This is a major hassle, and it is required if we want to be safe against man-in-the-middle attacks (MitM). This is not required, though: If we want to secure E-Mail for most users, we only need to ensure that a MitM is detected either when it starts or when it ends. That makes it arbitrarily expensive to realize mass surveillance, because it means that every MitM attack has to be preserved indefinitely: If it stops, the surveillance target will become suspicious and invest the effort to do a real key verification.

Detect start and end of MitM

This is no new idea: All this was already described in the GnuPG subproject STEED (whitepaper as PDF).

The most important part is to follow SSL/TLS and SSH by realizing TOFU for E-Mail: Trust on first use.

Usable key verification

Resilient interaction between different free clients

E-Mail clients frequently fail to verify E-Mails from other clients. We cannot fix unfree clients like Outlook, but the free ones can be changed to try again if a given method fails: Do everything possible to try to get the message to decrypted and the signature verified, even if that requires being more relaxed than specified by an RFC. Other programs won’t get fixed just because your program shows that they do it wrong. People will just stop using GnuPG.

A recent example of this problem (which bit me personally) is that Thunderbird with Enigmail 1.7.0 and 1.7.2 failed to verify mails from KMail, but it’s not the first time that there are problems between those two. Another is that Enigmail fails to verify a Mail from Horde with a user signature, because a space in the signature isn’t encoded correctly. It’s all and nice that this is wrong by Horde, but failing the verification without sensible error (which tells the user how to fix the issue) is the worst possible reaction. That’s as if a web browser would fail out whenever there’s a problem on a website: Users would just stop using that browser. For some reason developers think that not decrypting a GnuPG message even though there’s no security problem is somehow OK.

Making interaction between E-Mail clients resilient requires a shift in mentality: That it is the responsibility of every client author to not just send correct E-Mails but also to treat decoding received E-Mails from all existing (free) clients as crucial to their task: If this fails, then the program is broken (within reasonable limits: correctly receiving E-Mails must not become so hard that no one implements it).

Usable encrypted E-Mail

Ensure that most encrypted content stays encrypted after security breaches

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

Protect the subject line

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

Mask the date and time of communication

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

Mask the physical location

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.

Conclusion

We already have the basic technology for making E-Mail between trusted friends truly confidential again. We can hide

  • The content of the mail,
  • The topic by faking the subject,
  • The time when we talked by creating cover traffic and
  • Our physical location where we wrote from.

People can still find out who knows whom, but can no longer see when they talk, where they talk from or what they talk about.

„Seit ich meine E-Mails mit GnuPG verschlüssele, habe ich keine Ausschreibung mehr an eine US-Firma verloren.“ – Paul Sibel to Anna Gram from his towel on 2015-05-25. (english version from Google translate, slightly wrong but fun: "Ever since I encrypt my emails with GnuPG, I lost no invitation to a US company.")

So I call upon all E-Mail client developers: Please implement these measures to allow users to talk confidentially again. You do not need additional support from GnuPG for that. It can all be done in the code you know best.

We cannot make E-Mail pseudonymous, but at least we can make it confidential.

PS: The technology for this is not in E-Mail clients yet, so if you want confidential communication now, your best bet is to connect over Freenet – which additionally gives you pseudonymous communication. Using Freenet you regain the full set of communication options you have in the physical world:

  • confidential discussion in private,
  • self-censored public speech and
  • free pseudonymous publishing.

Inhalt abgleichen
Willkommen im Weltenwald!
((λ()'Dr.ArneBab))



Beliebte Inhalte

sn.1w6.org news