Given different people’s and community’s security needs, it’s hard to arrive at a consensus of what a “secure” messenger must provide. In this post, we discuss various options for developers to consider when working towards the goal of improving a messenger’s security. A messenger that’s perfectly secure for every single person is unlikely to exist, but there are still steps that developers can take to work towards that goal.

Messengers in the real world reflect a series of compromises by their creators. Technologists often think of those compromises in terms of what encryption algorithms or protocols are chosen. But the choices that undermine security in practice often lie far away from the encryption engine.

Encryption is the Easy Part

The most basic building block towards a secure messenger is end-to-end encryption. End-to-end encryption means that a messenger must encrypt messages in a way that nobody besides the intended recipient(s)—not messaging service providers, government authorities, or third-party hackers—can read them.

The choices that undermine security in practice often lie far away from the encryption engine.

The actual encryption is not the hard part. Most tools use very similar crypto primitives (e.g. AES, SHA2/3, and ECDH). The differences in algorithm choice rarely matter. Apps have evolved to use very similar encryption protocols (e.g. Signal's Double Ratchet). We expect that any application making a good-faith effort to provide this functionality will have published a documented security design.

Beyond encryption, all that’s left are the remaining details of product trade-offs and implementation difficulties, which is where the hottest debate over secure messaging lies.

Next: Important Details That Are Hard to Perfect

Every secure messaging app has to worry about code quality, user experience, and service availability. These features are hard to perfect, but putting no effort into them will render an application unusable.

When it comes to encrypted messaging apps, there’s a big difference between the theoretical security they provide and the practical security they provide. That’s because while the math behind an encryption algorithm may be flawless, a programmer may still make mistakes when translating that math into actual code. As a result, messengers vary in their implementation quality—i.e. how well the code was written, and how likely the code is to have bugs that could introduce security vulnerabilities.

Every secure messaging app has to worry about code quality, user experience, and service availability.

Code quality is particularly hard to assess, even by professional engineers. Whether the server and client codebases are open or closed source, they should be regularly audited by security specialists. When a codebase is open source, it can be reviewed by anyone, but it doesn’t mean that it has been, so being open source is not necessarily a guarantee of security. Nor is it a guarantee of insecurity: modern cryptography doesn’t require the encryption algorithm to be kept secret to function.

User experience quality can also vary, specifically with regard to the user’s ability to successfully send and receive encrypted messages. The goalpost here is that the user always sends messages encrypted such that only the intended recipients can read them. The user experience should be designed around reaching that goal.

While this goal seems straightforward, it’s difficult to achieve in practice. For example, say Alice sends a message to Bob. Before Bob can read it, he gets a new phone and has to update his encryption keys. Should Alice’s phone re-send the message to Bob’s new phone automatically, or wait for Alice to approve Bob’s new encryption keys before resending the message? What if Bob’s sister shoulder-surfed his password and signed into his account on her phone? If Alice’s phone re-sends the message on her behalf, she risks accidentally sending it to Bob’s sister instead of Bob.

Different applications might have different priorities about message delivery versus sticking to encryption guarantees, but we expect applications to make thoughtful choices and give advanced users the option to choose for themselves.

Like seatbelts and two-factor authentication, the biggest failure mode of secure messengers is not using them at all. If a tool fails to reliably deliver messages in congested or hostile network conditions, users may be forced to fall back to less secure channels. Building a reliable service takes consistent, applied engineering effort that smaller services might not have the resources for, but it’s essential to ensuring the user’s security.

Adding Security Features

Past these basic tenets of implementation and user experience, the discussion becomes thornier. Security benefits can get left behind when they’re deemed to not be worth the cost to implement or when they’re judged as detrimental to ease of use. We recommend considering some features in particular to create a more robust secure messenger.

There's a big difference between the theoretical and practical security messengers provide.

Modern messengers store conversation histories in the cloud. If a secure messenger stores the conversation history unencrypted in the cloud (or encrypted under information that the service provider can access), then the messenger might as well not have been end-to-end encrypted. Messengers can choose to encrypt the backups under a key kept on the user’s device or a password that only the users know, or it can choose to not encrypt the backups. If backups aren’t encrypted, they should be off by default and the user should have an opportunity to understand the implications of turning them on.

A secure application should have secure auto-updating mechanisms to quickly mitigate security problems. An out-of-date messenger with known security flaws is potentially vulnerable to more potent attacks than an up-to-date unencrypted messenger.

Perhaps surprisingly, a messenger being marketed as secure can undermine the goals of security. If having the application on a user’s phone is a marker that the user is trying to stay secure, that could make the person’s situation more dangerous. Say an outside party discovers that a person has a “secure” app on their phone. That app could be used as evidence that the person is engaging in an activity that the outside party doesn’t approve of, and invite retribution. The ideal secure messenger is primarily a messenger of sufficiently high popularity that its use is not suspicious.

An app may also choose to provide reliable indicators of compromise that are recognizable to an end-user, including in the event of machine-in-the-middle attacks or a compromised service provider. The application should also allow users to verify all their communications are encrypted to the correct person (i.e. fingerprint verification).

Finally, we recommend allowing users to choose an alias, instead of requiring that their only identifier be a phone number. For vulnerable users, a major identifier like a phone number could be private information; they shouldn’t have to give it out to get the benefits that a secure messenger provides.

Features to Look Forward To

In this section, we discuss the stretch goals that no major app has managed to implement yet, but that less popular apps or academic prototypes might have.

We’d love to see academics and experimental platforms begin working on delivering these in a scalable manner, but we don’t expect a major application to worry about these just yet.

While protecting the contents of messages is important, so too is protecting the metadata of who is talking to whom and when. When messages go through a central server, this is hard to mask. Hiding the network metadata is a feature we’d like to see grow past the experimental phase. Until then, we expect to see services retain only the metadata absolutely necessary to make the service function, and for the minimum possible time.

There's no consensus on what the best combination of features is, and there may never be.

Most messengers let users discover which of their existing contacts are already using the service, but they do so in a way that reveals the entire contents of a contact list to the service. This means that to find out which of your friends are using a service, you have to tell the service provider every person whose contact info you’ve saved to your phone, and you have no guarantee that they’re not saving this data to figure out who’s friends with whom—even for people who don’t use the service. Some messengers are already taking steps to make this information leakage a thing of the past.

Pushing reliable security updates is of prime importance to security. But automatically accepting new versions of applications means that users might inadvertently download a backdoored update onto this device. Using reproducible builds and binary transparency, users can at least ensure that the same update gets pushed to every user, so that targeted attacks become infeasible. Then, there’s a better chance that the backdooring will get noticed.

When a messenger allows group messaging, advanced security properties like future secrecy are lost. New protocols aim to fix these holes and give group messaging the security properties that users deserve.

In the secure messaging community, there's no consensus on what the best combination of features is, and there may never be. So while there will never be one perfectly secure messenger to rule them all, technical questions and conversations like the ones described above can move us towards better messengers providing more types of security.

This post is part of a series on secure messaging.
Find the full series here.