Email privacy crash course – Part 4: Usability vs. Security

The previous articles in this series covered email  Encryption, Metadata and Anonymity. We shall now explore the often neglected but arguably the most important aspect of email privacy solutions: usability.

 

Picture1

Why is usability important?

Ninety-nine per cent of the users will drop an email privacy solution like a hot brick if it makes email difficult to use. Unfortunately, some email privacy providers are enamored with the technical/crypto part of their solutions and fail to make them easy to use. Others do invest in usability but struggle with keeping their solutions secure. Typically for the available email privacy solutions, the more secure the solution, the less usable it is. Let us examine the security/usability trade-offs in a representative sample of existing solutions, as shown in the following picture.

 

Picture1

 

Security of stand-alone PGP clients such as browser plugin-based Mailvelope, native client-based Enigmail or mobile app APG is relatively very good: their decryption keys are generated and stored on your device; their code is open-source, is stored on your device and can be signed and recompiled by the user to verify its authenticity. However, the stand-alone clients are notoriously difficult to use. They burden users with key management, including manual import of addressees’ public keys and manual synchronization of keys between desktop and mobile devices. This makes usability of stand-alone PGP clients unacceptable for a great majority of email users – except geeks and dedicated privacy buffs.

On the other end of the security/usability spectrum are the server side encryption (SSE) services such as StartMail, Hushmail and TorGuard. Usability of these solutions is perfect: they allow use of any standard email client on any mobile or desktop device. However, their security is unacceptable. We have described this in detail in Part 2 and can only repeat here – do not use these services unless you are OK with your emails being disclosed in clear text to the “secure” SSE service providers.

This leaves the middle of the road JavaScript-based email encryption services with central key management such as Tutanota, Ghostmail and Protonmail. Their usability is a significant improvement on that of stand-alone PGP clients – the users do not have to manage encryption keys, and the synchronization of keys between user devices is automatic. However, while due to end-to-end encryption these services are much more secure than the SSE services, their security is considered by some to be slightly lower that that of native email clients, due to their use of JavaScript on the client side.

Tutanota (and apparently also Ghostmail) go a step further by facilitating a single password for both account access and private key decryption. While having to input one password instead of two improves usability, Tutanota achieved this by doing client-side password hashing – a technique widely considered to be insecure. Since Protonmail uses two separate passwords, it is more difficult to use but more secure than Tutanota. Note that unlike the SSE and stand-alone PGP client based solutions, both Protonmail and Tutanota suffer from people network and ubiquity limitations. These are discussed in detail in Part 5.

While choosing among email privacy solutions you should, among other factors, balance security and usability. Bear in mind that, as discussed in Part 3, all the email privacy services mentioned above encrypt email content but fail to protect your metadata.

Are you a privacy purist?

You will find them on every forum discussing secure email or messaging systems – privacy hobbyists who derive aesthetic (or fetishist) pleasure from building complex multi-layer secure messaging schemes using several existing tools in tandem, aiming at perfect security and anonymity and spending 10 minutes to send a single message to other enthusiasts. Usability is the least of their concerns. They will painstakingly perform GPG encryption of message text and then manually paste the resulting armored ASCII text into SIGAINT using Tor browser in the no-JavaScript mode; or they will hash a picture and use the result as a password for AES encryption, while providing the picture anonymously to their correspondent over a separate secure channel, as a shared secret.

In cases of privacy being extremely important to you and the other party willing to cooperate, by all means consider using such schemes; but if you are just an email user who does not like the idea of mass surveillance or wants to keep his personal and business transactions private, stick to one of the PGP-based email privacy services that provides you with an optimal combination of usability, people network and metadata protection.

Solutions in development

Some interesting new solutions that are still in development (more about it in Part 6: Make your choice).

Mailpile is a stand-alone PGP client with a twist: it periodically downloads all your email into your computer and deletes it from the server. You can access your email at your computer (when it is running), or from another computer using a browser. However, this creates serious issues with both security (you need to secure your computer very thoroughly) and usability (your mail can be lost unless you spend a considerable effort on backing up your computer; for outside access you need to reconfigure your home firewall, which is beyond almost all users).

DarkMail is a complex new specification and open source development led by the former owner of Lavabit. DarkMail encrypts email metadata in a way that minimizes its exposure as the email traverses the untrusted networks, and provides separate encryption of different parts of email messages, significantly improving security. However, usability of DarkMail is questionable, as it requires both replacement of email clients and modification of the entire SMTP infrastructure. We do not believe that such modification  is possible in the observable future.

What about non-email messaging?

This series is about the privacy of email, not of instant messaging. The great, unbeatable advantages of email are its ubiquity and usability – everybody uses it, and it is easily accessible from any device. However, instant messaging has also grown to be very popular, and some IM services are more advanced than email in protecting your privacy. Below is an overview of a sample of such services, along with some advice to privacy-sensitive users of IM.

Do not trust “secure” IM providers that do not publish their source code. This includes Apple’s iMessage, WhatsApp, Google’s Allo, Threema and Facebook’s Messenger. If they do not publish the source code, you (and the security research community) can never know what they are really doing. End-to-end encryption conflicts with other services they are trying to piggy-back on their IM, such as AI bots. Moreover, they often issue misleading statements or tell half-truths. For example, WhatsApp are backing up your messages unencrypted on Google servers – not exactly our idea of end-to-end encryption. Google made their Allo non-encrypting by default – who knows how many users will overlook this. Reportedly Facebook plan to do the same with Messenger. Apple can read your iMessages stored on iCloud for backup.

Pure open source IM providers are more trustworthy but you need to do some research and read reviews. Among these, Bitmessage, Signal, Telegram and Ricochet, while still being considered experimental as they have not suffered through many years of hacking attacks, are popular. Unfortunately, they cannot even come close to the people network, ubiquity and ease of use of email or WhatsApp, and thus their use remains very limited (with the exception of Telegram that was taken up massively in Iran). Telegram is, however, considered by the security community to be problematic in terms of operational security.

Decentralized secure IM services provide better anonymity and resilience to attacks. Telegram and Signal use central servers, which makes them vulnerable. Moreover, both of them require your phone number for authentication or registration, defeating anonymity. The decentralized, peer-to-peer Bitmessage and Ricochet seem to be (experimental but) solid. Both feature end-to-end encryption and excellent metadata protection and anonymity. However, neither of the two is available on mobile devices, implying poor usability. Also, do not use Bitmessage in their “email” mode – this turns out to be just another SSE service as your messages emerge unencrypted on their email gateway.

Our next article is Part 5: Ubiquity and people network.

 

7 comments

  1. Martin Allien

    First of all, thanks for this series. I discovered and started encrypting my email about a year ago and even if I still research better ways how to achieve it, this series helped me understand a lot.

    After reading this article, I have a few questions:

    1/ You write here that “all the email privacy services mentioned above encrypt email content but fail to protect your metadata.” – isn’t that false for Tutanota and ProtonMail? At least they are marketing that their encryption hides metadata as well (or is that just email headers?).

    2/ IMs: Any reason why you haven’t included Threema? It’s security, usability and anonymity (no need for telephone number) makes it a very competing alternative to the others. However it does suffer a bit from “small” network effect.. (I’m trying to correct it this way a bit I suppose 🙂

    All that being said, can’t wait for another posts on the topic!

    • EasyCrypt

      Thank you for your comments. Metadata is protected when the provider has zero knowledge of it, which means that the provider is technically unable to store or read it. Otherwise, it is not protected, full stop.

       

      Protonmail does not protect metadata. Specifically, Protonmail has your IP address and your identifying email address (unless you pay them to be able to register with Tor, and for the payment you are required to use your credit card). If you do not connect to Protonmail with Tor with JavaScript enabled, it also has your IP address for every mail reading or writing session. Moreover, Protonmail learns your IP address every time you connect from your mobile devices, and it always knows the email addresses (and hence the identities) of the sender and the recipients of all your messages, as well as the subject lines of your messages. All this metadata is unprotected and technically can (and therefore will) be given away under a strong enough pressure from a government.

       

      Tutanota, unlike Protonmail, claim to encrypt the subject line (presumably with the same public key as the body and the attachment of the message). We have no reason to doubt this claim – their code is open source. The rest of the metadata is as unprotected in the case of Tutanota as in the case of Protonmail.

       

      We did not include Threema because this was not an exhaustive review of IM services, we just provided a sample of them. Threema do claim metadata protection that is in line with our definition. However, Threema does not publish its source code and therefore falls under our blanket warning: do not trust services that do not publish their source code.

    • eastcoastdoll

      Very thorough & simple verbage. Thank-you very very
      much.

  2. Sean (@shon_ondray)

    Telegram is not encrypted by default. It falls into the same category as Allo and Facebook Messenger b/c you have to choose secret chat. Also, only the clientside is open source while the server side isn’t. Signal has both open sourced (well except for their former Red Phone server side)

    Nobody does any encryption with metadata. Signal claims to delete it all from their server and I read a Motherboard article where a WhatsApp rep say they don’t currently keep metadata (but they can start anytime without anyone knowing).

    The next step is to start encrypting metadata otherwise using email is pointless if you want to have any sort of privacy. Its an outdated way of communicating because of all the leaks and the difficulty of staying private. Prob should type message in a document and send it via Signal. Just some quick thoughts. Good articles though.

    • EasyCrypt

      While we do not think that Telegram falls exactly into the same category as Allo and Facebook, technically you are correct – if they do not release ALL their source code, servers included, they are always suspect and cannot be considered zero-knowledge. They are, however, as easy to use as WhatsApp but more secure, and we do advocate balance between usability and security, the alternative being (for many impatient users) no security at all.

      Trusting service providers is a stupid concept. Either they prove that they are zero-knowledge or they are not zero-knowledge – there are no shades of grey. Therefore statements like “we do not log your metadata” are a joke. If they CAN log our metadata, the working assumption must be that they ARE doing it (or WILL start doing it any time, without telling us).

      There are some initiatives towards encrypting metadata of email, including DIME and Memoryhole. However, these seem to imply the need for changes in email network infrastructure and we do not believe that such changes are possible – the email network is too large, too decentralized and too valuable for that. The right answer will be to do it at the endpoints only.

  3. DaEmailHater

    Excellent read and thanks for the post.

    Protonmail now has one login password by default. The two password scheme that you mention: one for authentication and one for the mailbox is now considered legacy. Details here:

    https://protonmail.com/blog/encrypted_email_authentication/

    They now use the SRP protocol. It’s supposed to all happen client side. They now derive the mailbox password from the login password hash +salt, as far as I understand. How does that improve their service? Any opinion on that implementation? It seems to be weaker IMHO but increases usability.

  4. DaEmailHater

    Signal apparently does not store or keep the users’ phone numbers but a hash instead is used for contact discovery:

    https://whispersystems.org/blog/contact-discovery/

Send this to a friend