Editor’s note: This article is the first in a series focusing on the best encrypted apps and services available. Content has been provided by an anonymous security and privacy professional. Readers are encouraged to confirm this information on their own.

Who is this for?

Anyone who needs to communicate electronically. Sending an email or an SMS may feel like the electronic equivalent of sending a letter, but it’s actually more like a postcard. Seriously. It was recently reported in the Wall Street Journal that Gmail gives plaintext emails to third party developers. That is to say, humans not even within Google can and do read Gmail users’ emails, with no technological or even legal barrier, whatsoever. So if you use email and SMS for anything you wouldn’t put on a postcard (and I think that that’s pretty much all of us), you need encryption.

What is encrypted communication?

“Encrypted communication” should refer to end-to-end communication, meaning that your message is encrypted when you hit “send” and decrypted when the recipient opens it, and the decryption key is never stored with the message. If you use a normal communication service, one or both of these things won’t be true; in 2018, the service almost certainly uses HTTPS (please install HTTPS Everywhere, if you haven’t already – it defaults to the HTTPS versions of sites, where available) to encrypt traffic between your computer and their server (you may also see the protocol listed as SSL and/or TLS), but once the email is on their server, that layer of encryption is removed and anyone with access to the server has access to the emails stored on it. This is how your emails are scanned to better advertise to you (or read by human workers, as in the WSJ story above), and one way governments spy on their citizens (if they don’t intercept messages as they’re being sent, they can just request them from the provider, along with the decryption key). Encrypted communication apps/services are also sometimes called “zero knowledge” or “zero access” providers, to reflect their inability to read the messages stored on their servers.

For email, at least, the technology is nothing new, but packaging it with the email service has only proliferated recently; until a few years ago, you almost certainly used a browser extension linked to your email account or a plugin for your email client… and the extension was only released in 2012, with the official stable release being earlier this year.

Encrypted email typically comes in two forms. One is for in-network emails, and is a very “invisible” or seamless user experience where emails can be sent and opened normally. And one is for out-of-network emails, which requires a password both parties have agreed on and the recipient decrypts and responds to via a web interface. Encrypted instant messaging either has no out-of-network function or uses a non-encrypted format.

The method commonly used in-network for email is known as “public key” or “asymmetric” encryption. This means that there are different keys for encrypting and decrypting messages, solving the problem of the sender and recipient agreeing on and keeping track of a password. This may also be referred to as “RSA,” the original algorithm and the initials of its inventors, or “PGP,” “Pretty Good Privacy” and a widely adopted implementation of the algorithm (“OpenPGP,” an encryption standard, to be specific). For password-protected messages, AES is likely to be used. Both of these ciphers are cryptographically secure: Current methods of encryption are superior to methods of cryptanalysis; if your communications are “attacked,” the attack is practically certain to be on the web/app interface*, the operating system, and/or the users. For chat/instant messaging, AES and a method of secure key exchange are the current standard.

What is not encrypted is metadata: the sender, the recipient, the subject line (as applicable), and the time sent. It’s possible to encrypt email subject lines within the network, but only the email provider Tutanota does it, because it slows the user experience. If you’re an activist in an authoritarian state and/or are being hunted by a technologically sophisticated terrorist cell, be sure to use TOR or a VPN, so that metadata is encrypted as it’s transmitted to and from your device or web browser. (El Chapo and Paul Manafort both made the mistake of using encrypted apps, but not VPNs, when hiding from the law and witness tampering, respectively, for examples of metadata biting someone in the ass. As for the rest of the body, former director of the NSA and CIA General Michael Hayden notes, “We kill people based on metadata.” Privacy and security people aren’t as interested in criminals and terrorists as this parenthetical may make it seem, it’s just that their capture and prosecution give glimpses of what state actors are capable of.) The Electronic Frontier Foundation offers some practical examples of how metadata collection can invade your privacy:

• They know you rang a phone sex line at 2:24 am and spoke for 18 minutes. But they don’t know what you talked about.
• They know you called the suicide prevention hotline from the Golden Gate Bridge. But the topic of the call remains a secret.
• They know you got an email from an HIV testing service, then called your doctor, then visited an HIV support group website in the same hour. But they don’t know what was in the email or what you talked about on the phone.
• They know you received an email from a digital rights activist group with the subject line “52 hours left to stop SOPA” and then called your elected representative immediately after. But the content of those communications remains safe from government intrusion.
• They know you called a gynecologist, spoke for a half hour, and then searched online for the local abortion clinic’s number later that day. But nobody knows what you spoke about.

Presuppose that several sources of metadata are being collected, but how many people use Gmail, an Android phone, and the Chrome web browser? Or if you have Facebook open and aren’t using container tabs, it can read cookies from other sites you visit, while their mobile app logs your calls and uploads your contacts. This, in addition to usability, is why I don’t recommend standalone encryption tools paired with “free” communication tools, or even encrypted messengers from companies that aren’t in it out of genuine respect for privacy.

Even though public key encryption has become standardized, note that interoperability is a work in progress; again, the public key encryption and email technologies are each well established, but integrating public key encryption seamlessly into an email interface and the “behind the scenes” key management and distribution that go into it are new. One provider, Posteo, allows non-users to enter their public key into their key directory and another, ProtonMail, just released adding a non-user’s public key as a contact detail from beta, last July. Ideally, all services using OpenPGP would have both options, and I hope that is someday the case. (But if using a standalone PGP email tool, all parties need to send each other their respective public keys, before encrypted email can be exchanged, anyway.) Tutanota is the exception to many things, PGP included, so interoperability is unlikely to ever be added; ditto instant messengers.

A question you may be asking yourself right about now: Should you use encrypted email and messaging, even if you can’t get anyone else in your social circle to? The answer is a resounding, “Yes!” You should still use encrypted email and messaging, because if your own email provider is “zero knowledge,” a data breach at your own email provider will not put the content of your emails at risk, and no other data breach will contain every email. And if you use symmetric encryption for all of your out of network emails, a breach or leak at another email provider won’t expose any email text at all.

It is important to note that while all of my top recommendations are audited, you have to trust the provider to use the audited code. In the mid-2000s, encrypted email provider Hushmail was able to decrypt the emails of at least one suspected criminal, after being issued a court order. Hushmail offered both decryption and encryption by a downloaded applet, more secure, and decryption and encryption on their own servers, faster and more convenient. Presumably, the suspected criminal chose the latter, in which case Hushmail had his key briefly unencrypted on their servers, which they could presumably be ordered by a court to retain for later use. But it is an acknowledged technological possibility that they could have created a malicious variant of their applet for use when court ordered to decrypt emails. To the best of my knowledge (and, it seems, the much more knowledgeable minds in Apple’s legal team), it is dubious that a court can force a technology company (with a large legal team, at least) to create a tool to harm their users, but the fact remains that there’s an element of trust involved. Nowadays, JavaScript handles decryption and encryption within the user’s browser, so you could hypothetically check that you’re getting the expected code each time you log on, but no one would actually do this. I contacted the EFF’s extension team to see if this could be done automatically by a browser extension, and a senior technologist wrote back saying that it’s possible, just difficult. Hopefully someone smarter than me will get to work on that.

Continued in Part II