Decoding the hidden trade-offs of E2EE and usability

In an ideal world, end-to-end encrypted (E2EE) messaging apps would work identically to their non-E2EE counterparts (e.g. transport-layer security only), without introducing any additional inconvenience for users.

In reality, in an environment where the server should not have the ability to read any of your messages, many “simple” problems become much harder to solve. Every user who has tried using an E2EE messaging app for some time, has probably felt the results of that one way or the other. Perhaps when you first sign up, and start on just one of your devices, everything seems as usual. You can create chats, you can send and receive messages. However, when you want to add a new device, or when you lose your very first device, things get more challenging - the usual “everything is in the cloud and I can unlock it with a reset to my password”, is no longer true.

Without an always-on server which is trusted to access users’ messages, things become challenging because users often have many devices - phones, tablets, laptops, etc. They may need to have a new device at any time, they may lose their devices - and it could be that at some point they have lost all of their devices. As usual, there are tradeoffs in solving those new challenges and, because no one has infinite budgets or time to launch their product, compromises have to be made. Those could be limitations on how the app can be used (for example, most apps have limitations on how many devices you can log into), a more complex model that the user needs to understand (many apps have a concept of a special “primary” device which is harder to replace than other “linked” devices) or additional user responsibilities (if you want to get access to your messaging history even if you have no logged in devices, you must have previously securely stored a recovery key for that purpose). As the technology matures, it is expected that some of these limitations will be eliminated or relaxed and user experience will improve at the same time. However, there will always be something that can not be fully eliminated compared to a non-E2EE app. If you have an electric car - even if the range and charging experience improve over time, you still need to charge it.

As one might expect, not all vendors have made the same amount or type of compromises. Let’s see how they compare in terms of the limitations that they have and the corresponding user experience.

Let’s start with the number of devices. Element does not limit the number of devices a user can have. You can have any number of desktop or mobile devices, using either native apps or browsers to connect. This is of course great from a user experience point of view - there’s no friction, just like a non-E2EE app. Also, the model is straightforward because there is no differentiation of “primary” or “linked” device. You can at any time add a laptop, throw away your old phone, and then add a new phone later - everything keeps working. If you need to have two phones, you can have two phones. All devices are “equal” and provide all the available features.

In contrast, WhatsApp and Signal enable just one (primary) phone and then a few linked devices (tablets, laptop). WhatsApp does have “companion mode” which allows the addition of up to four “companion phones” but there are limitations such as the need to log in to the primary phone at least every 14 days, to keep your account active. Threema 2.0 (still in Beta) has support for multiple devices, but it is still limited to one primary phone and a couple of linked devices. Wire is limited to eight devices out of which one can be a temporary device. Telegram does not directly limit the number of devices, however, E2EE chats only work on a specific device where you start them - which essentially limits them to a single device; hence Telegram is also not considered in the remainder of this blog as it is much more limited and hard to compare to the other E2EE apps which are at least attempting to make E2EE work in a device-agnostic manner.

Another classical hurdle for E2EE apps, has been the ability to access your messaging history on a new device that you have just added. Element provides that in a seamless manner. It works out of the box, with no specific user actions required to make the history visible. There are also no limitations on how far back you can go - you get the whole history. Of course, signing in to a new device on Element requires you to either have access to one of your existing devices or to your recovery key¹ (a 48-character random secret that only you know) - but that is a security feature which is hard to avoid and which serves several other purposes besides seeing the history on a new device. For super-sensitive users or use cases, there is an option to turn this feature off.

The other apps have limitations on what you can see on the new device or how much manual effort is needed to see it. Essentially, two categories exist.

WhatsApp and Signal automatically provide you with the history on the linked device; and of course you need your primary device to link a new device to do that. There are limitations, though. WhatsApp provides you with a history of 12 months. Signal provides you with unlimited history of text messages but media is limited to 45 days (as media itself is not embedded in the transferred data - a link to a copy on Signal’s servers is sent instead, and on Signal’s servers the retention is 45 days).

Note that the above only applies when you add a new linked device. If you’re replacing your primary phone, it is a different story. In that case, to get your history on the new primary device, you have to restore it from cloud backup (assuming you have set it up before) or use a phone-to-phone transfer (assuming you still have your old device).

Wire and Threema do not offer any chat history on a linked device in a seamless automated manner. You need to manually export and import between the two devices. The Threema Safe allows you to sync your ID and contacts, but not the chat history.

What about accessing the history when you have lost all of your existing devices? This does not mean that all of those devices have physically ceased to exist, but that they are no longer accessible to you - the apps and data may have been wiped, etc.

In the case of Element that is straightforward - as long as you remember where you stored your recovery key and can get it, you can retain access to the full history of all your chats. This of course does come with some additional responsibilities on the user side when compared to non-E2EE apps

• the user needs to set up recovery, which is a very simple process: the user is prompted to do it in the app and there are no external dependencies (such as a cloud provider for backup storage)
• the user must also securely store the recovery key (a 48-character secret generated during the recovery setup process).

However, the user does not need to think about where to store the backups, how often to create them, or how to secure them. How much friction storing the recovery key causes depends on the use case and environment - but it is certainly, both easier and safer, than asking the user to manually create backups and restore them - and still remember the decryption key. A typical consumer can store the recovery key in their favourite password manager together with the other secrets they have to remember. The experience for such users can also be relatively easily improved by providing an integration with the password manager, instead of manual copy and paste. There are also organisations who deploy password managers for their staff, but that is not always the case. Organisations always prefer a unified and automated solution that works the same way for all of their users, rather than relying on each of their employees to go and store it in their password manager in the correct manner. Thus, in such an environment, the challenges are harder to overcome.

Signal and WhatsApp are somewhat similar to Element, since there is a “cloud backup” option, but the implementation is different. WhatsApp depends on iCloud or Google for the backup storage. Signal does not depend on external platforms, and hence you always need your recovery key, just like with Element, to recover your history. WhatsApp allows you to just use the encryption provided by the platform (iCloud or Google), but you can add another layer of encryption if you want, in which case you also need to store the recovery key for decryption.

Wire and Threema do not offer anything automated out of the box: you would need to create backup files manually and export them to a location where you want to store them.

What about the ability to retain your cryptographic ID when you lose all of your devices?

In case of E2EE messaging, the username and password (or phone number, depending on the app) to log into your account are still needed and useful for a number of things. However, such authentication of yourself to your provider is not sufficient for end-to-end encryption. For that purpose each of the users (and their devices) have a key pair that is generated in their device when they log in for the first time.

For those who are not familiar with the basics of cryptography - imagine if Alice had an infinite number of locks which all open with a key that only Alice has. If Alice wants Bob to send her something securely, they meet and Alice gives Bob a large portion of these locks - in an open state so that Bob can use them to lock a package but only Alice has the key to open the package. This key and the locks can be considered as Alice’s cryptographic ID. Of course, this is a simplification because in reality each message is not directly locked (encrypted) with the same lock/key but it is good enough for explaining and understanding the problem.

The problem is that only Alice (and her devices) can have that key - otherwise it would not be E2EE - and if all her devices are gone, the key is gone too. That means, Alice needs to get a new key and corresponding infinite amount of locks. While this part is easy, she also needs to meet Bob, and everyone else she is messaging, to hand over the new locks to send her the messages so that she can open them. Such in-person handover is needed, as otherwise somebody could impersonate Alice and start stealing and opening the packages Bob is going to send to Alice.

While in a virtual world there is no literal in-person meeting to hand over the locks, there is still effort involved for both Bob and Alice in order to keep things secure in case Alice resets their ID. The minimum is that Bob is notified about that reset - which gives Bob at least the ability to check with Alice (via other independent channels) if it was really her who lost the key, and had to reset. Another layer of protection that some of the apps apply is to block messaging with Alice and require the two users to perform a verification of the new ID (involves communication via another independent channel) to make sure that a man-in-the middle is not spoofing Alice’s new ID. This is typically the case if Alice and Bob performed such a verification when they first started to communicate.

Different apps use different wording (e.g. “Your security code with Bob has changed” or “Bob’s identity was reset”), and they make it more or less prominent, but essentially they are all pointing out the same issue that is described above. Thus, it is also obvious that such ID resets should happen as rarely as possible - otherwise they become noise that everybody just ignores and no one ever bothers to check if this was the person themselves or a malicious party. In particular, because most regular users probably won’t understand what this exactly means and how to behave, it is something that does not exist in the non-E2EE world.

In the case of Element, the cryptographic ID is backed up to the server when you set up recovery (the same recovery that is mentioned above for message history). While the corresponding key-pair leaves your device, it is encrypted with your recovery key. Thus if you have access to your recovery key, you can always retain your ID and can continue communicating with your contacts as if nothing happened. This is, of course, a trade-off - having to reset your ID often is bad, but if your recovery key leaks or gets stolen, your ID gets stolen as well. Thus, setting up recovery on Element is not mandatory and each customer or user can choose the right level and type of protection depending on their use case and scenarios.

Signal does not offer an option to back up your cryptographic ID, even when you have set up the (message) backup, and have your recovery key. You can get access to your message history, but you need to create a new ID. WhatsApp behaves effectively in the same way - there’s no way to retain your cryptographic ID.

Threema does offer the option to retain the ID via the Threema Safe. To restore your identity, you need to know your 12-word recovery phrase or QR code.

Wire offers to retain your ID via its ID Shield feature (only available on the on-premise deployment, and requires a paid enterprise plan) without the user needing to store a recovery key or a similar secret. However, since it is accomplished via a server-side central and trusted infrastructure (e.g. a certificate authority issues a certificate, if the user provides enough proof of their identity), it can not be considered a superior solution but rather a trade-off where the trust anchor moves from the users (and their devices) to a trusted server.

That’s not all! There are more features that look “obvious” for anyone who has used a messenger before but which are not necessarily available in the context of E2EE messaging. One of them is the ability to get access to past messages when you join a group chat. If you told anyone using Slack or Teams that they could not see history when they are invited to a channel, they would find this shockingly bad. Now, to be fair, there are cases when you do not want that - but it's one thing not to want this for a specific chat, and quite another not to have it at all. In most workplace use cases, this ability is a must-have.

In the case of Element, we allow² the user to decide for each group chat whether they want historic messages to be shared with new members or not: if they are shared then users are able to see and successfully decrypt those historic messages. This applies to the entire history of the chat, and if someone changed the history visibility setting during the lifetime of the chat, only messages sent during the time when history sharing was turned on are accessible. A current limitation is that the new user needs to be explicitly invited (added) to the group chat by someone because someone needs to share the decryption keys for those historic messages (this is worth highlighting because there are other ways to join a chat on Element besides being explicitly added by someone).

Signal, Threema and Wire have no ability to provide history to someone who was added to the chat later. WhatsApp is able to provide a history of the last 24 hours. It is limited because the admin of the chat is re-encrypting those messages for the new member.

Finally, what about the ability to read messages that were sent while you were logged out everywhere? It is again something that is obvious in non-E2EE messaging - but becomes difficult to accomplish if you can only rely on end-users' devices.

Element currently offers limited support for this (requires using Element Web or Desktop client, with experimental MSC3814 explicitly enabled on the server) in a beta stage. It creates a virtual device (via a process called device dehydration) for the user and stores it on the server so that messages can still be encrypted for this user, even if the user has zero physical logged-in devices. The entire virtual device is fully encrypted on the server and no secrets are available to malicious admins or men-in-the-middle, but as it potentially still increases the attack surface (given an attacker who manages to dehydrate the device can steal both your identity and message history), it is only activated when the user has set up recovery and is ready to make that trade-off.

On WhatsApp (primary phone) there’s no literal logout button - because that would only cause you trouble. However, an equivalent situation occurs when you uninstall WhatsApp on that physical device and then install it on a different device. In such a case you may be able to receive and decrypt the messages that were sent while you did not have a running app on any of your devices. It is a “maybe”, because it requires the sender to be online (in order to re-encrypt the message for the new device) and it works only if not too much time has passed since sending the original message (exact limit not known, but 24h was not too much).

Signal is similar in the sense that there is no literal logout button on the primary phone, but unlike WhatsApp, the messages that were sent while you had no app running won’t ever be delivered to you.

Wire offers you two ways of logging out. If you log out without “Deleting all your personal information and conversations on this device” - you are able to get and decrypt the pending messages that were sent while you were logged out. This means the cryptographic keys that power the E2EE are kept on the device. If you choose to delete this data when you’re logging out, you’re not able to get any of the pending messages when you log back in.

Threema does not also offer a literal logout function but you can delete your data on the given device, or you can reinstall the app to simulate that. None of the backup functions (e.g. the Threema Safe or the Backup on local device) will provide you with the messages that were sent while you had no devices.

As a summary, Element is able to offer many of the table stake features of non-E2EE apps, for example accessing history on new devices, accessing history when you lose all of your devices and retaining your ID when you lose all of your devices. It can do that with a simple device model (e.g. no limited number of primary or linked devices and the related complexities that the user has to learn), and offers the ability to configure the app according to the needs of the use case - balancing privacy and convenience. There are of course some new things the end user needs to do and learn - what a recovery key is, how to securely store it and when to use it; but fortunately, that is the only thing the user has to learn to get almost the same experience as with non-E2EE apps. We are continuing to find ways to make storing and retrieving the recovery key both easier and more secure for the end users.

¹ For the sake of clarity, besides a generated key, in the past Element apps also allowed the users to enter their own passphrase for recovery purposes.
² This feature will be generally available soon, but early adopters can already try it out by turning on the feature flag “Share encrypted history with new members” under Labs (in Element Web/Desktop) or Developer Settings (in Element X, mobile).