Messaging Encryption Has Come a Long Way, but Falls Short
We’ve had a pretty good couple of years when it comes to messaging security. Initially, adopting encryption stopped passive surveillance. Later, adoption of end-to-end encryption by the dominant platforms gave us much needed privacy. Some platforms, such as Apple and Signal, even led the way when it comes to resilience against cryptographically relevant quantum computers. Compare this situation to the poor state of email encryption, and the difference is like night and day. Despite this, some structural problems remain, and we’re even in danger of regressing.
At a glance, end-to-end encryption (E2EE) is widely available, but if we look closely, we see many gaps:
- Apple users enjoy E2EE with post-quantum safety. Unfortunately, Apple doesn’t encrypt phone backups by default, which puts iMessage content in their hands and unprotected. Upgrading to Advanced Data Protection (ADP) fixes this, but it’s not effective when messages exist in the backups of all people involved in the communication chain.
- Android users also enjoy E2EE, although the protocol is yet to be upgraded with post-quantum cryptography. Google encrypts Android backups by default.
- Signal users enjoy E2EE with post-quantum safety. Signal wisely decided to exclude its data from backup on iOS, keeping the messages safe. Unfortunately, this means that your messages are not backed up, but there is an optional and fully encrypted paid service available from Signal directly.
- WhatsApp is also in the E2EE club, with the work on post-quantum safety still in progress. WhatsApp has the same problem with backups on iOS. Encrypted backup is available as an option, but that’s not really helpful unless you get all your contacts to do the same.
We are, unfortunately, in a place where we cannot rely on native platform messaging for secure communication. Interoperability can probably be fixed, at least between Apple and Google. Apple is currently working on implementing the latest Rich Communication Services (RCS) standard that comes with E2EE based on the MLS standard (RFC 9420). To achieve interoperable end-to-end security, we’d also need Apple to change its stance on encrypting backups. However, it’s the centralized implementation of messaging that represents the biggest problem. It’s a huge and defining structural issue. The centralization puts valuable messages in the hands of the vendors and makes them a very juicy target; they are in the crosshairs of commercial entities, legislators, law enforcement, and interest groups. None of them can be trusted when it comes to privacy. So we have a problem: The centralized implementations have made it possible to innovate and improve quickly, but they’ve also become chokepoints that can lead to breaking security for everyone at a stroke.
Even in the best case, where the encryption is left alone and by some miracle there are no backdoors, the fact that the metadata is concentrated in a few locations is a substantial problem.
Signal is the best option if you want reliable security, but the platform is not popular enough; good luck convincing every one of your friends to use it. Signal also has the problem of being run by only one entity. On the positive side, its clients are open source, and there is even a reproducible build for Android. This goes a long way toward transparency. The other platforms have to be continuously reverse engineered, which is a much more demanding effort.
There isn’t going to be an easy way out of this situation. No one has been able to build a robust, usable, and widely adopted E2EE solution for messaging. It’s a significant challenge, and many with smaller ambitions have failed as well. Is the current compromise and constant battle among the conflicting pulling forces the best we can do?
What’s Going on in the World Right Now?
- In the EU, Chat Control has been on the agenda for most of 2025. The fight for privacy is less intense this year, but continues nevertheless.
- In Russia, many messenger platforms are banned or restricted, with the government pushing the state-developed Max chat application. Just this week, they opened a criminal case into Telegram founder Pavel Durov.
- In the UK, Apple users are not able to enable Advanced Data Protection because of a standoff between Apple and the UK government.
- In the US, there is a new lawsuit against WhatsApp, alleging that its E2EE claims are a sham. Matthew Green has written a great blog post that goes into some detail about the lawsuits and shares some thoughts on trust. Meta, given its inherent incentives and history, cannot be trusted. Generally speaking, we shouldn’t need to trust corporations to enjoy privacy.
- Apple is being sued because it “prioritized user privacy over child safety for years,” as is Meta.
- Apple and Google are starting to test RCS interoperability.
- Group membership in messaging applications remains a rough edge. WhatsApp servers, for example, can add anyone to the conversation, which makes targeted surveillance trivial. Signal has a better story here, as the protocol requires that someone already in the conversation endorses the new arrivals.
- Key verification remains the weakest point when real security is required. Key transparency is a great initiative, but can we trust the closed-source clients to do the right thing?
- Off-device AI assistance is a new attack vector. It breaks E2EE by sharing message data with someone who is not the intended recipient. Meta claims to have implemented this feature in a privacy-preserving manner using trusted execution environments (TEEs), but it’s not something we can reliably verify.
- Age-verification requirements are spreading, with Discord announcing compliance most recently. Governments were too quick to legislate; they should have first explored and ensured that this is a problem that can be solved in a satisfactory and privacy-preserving manner.
- The FBI reportedly couldn’t get into a Washington Post reporter’s iPhone because it was in lockdown mode. They did, however, gain access to the reporter’s laptop by forcing them to use their fingerprint. Inside, they accessed the available Signal messages (disappearing messages had been enabled).
|
Short News
- The PLANTS IETF Working Group, which was created to take certificates into the post-quantum future, has adopted the starting document as the official starting point for the work.
- Let’s Encrypt has announced that it will support DNS-PERSIST-01, the new ACME validation method that supports long-term bonds between domains and CAs that are allowed to issue. Ryan Hurst looks back at the three decades of domain control validation.
- Apple has updated its Platform Security documentation, all 250 pages of it. Make sure that you read the PDF version using the link we provided. For some reason, some parts of the world are still shown the older, 2024 version.
- Certbot has been updated with support for IP address certificates.
- There is a new research paper claiming a tenfold improvement in RSA factorization using quantum computers, to only 100,000 physical qubits. Scott Aaronson examined the claims.
- If you’re involved with post-quantum cryptography, you should read Robert Campbell’s research paper on migration in enterprise environments. Marin likes it, and that’s good enough for me.
- In Android 17, Certificate Transparency is enabled by default. This is a change from the opt-in approach in Android 16.
- In December, Jon Seager announced the beginning of work on upki, a project that aims to add support for CRL-based revocation to Linux servers via CRLite. There is now a progress update. The project is possibly looking to expand into adding support for Certificate Transparency.
- ETH Zurich has been auditing password managers, focusing on the malicious server angle; problems have been found with Bitwarden, LastPass, and Dashlane. Here’s the direct link to the research paper. A Reddit user claims they were ignored after reporting some of these problems in 2021. 1Password said the new research didn’t find any new attack vectors in its products.
- The Security Cryptography Whatever podcast has a new episode covering the breakup of Python Cryptography with OpenSSL. We covered these developments in our December 2025 newsletter, and later included a follow-up.
- Chrome’s latest Root Program Policy, version 1.8, introduces stricter requirements for CA operations. It includes a small and largely symbolic requirement that all precertificates must be recorded in CT logs.
- Matthew Green reshared a paper from 2021 that provides statistical proof of a backdoor in the commonly used GSM encryption algorithms.
- Jean-Philippe Aumasson’s Too Much Crypto research paper makes a claim that many symmetric cryptography primitives would not be less safe with significantly fewer rounds.
- Fancy cryptography on GitHub is a curated list of projects that use cryptography in a way that goes beyond the usual and boring.
- Trail of Bits has been working with Sigstore to add cryptographic agility, ensuring it stays relevant in the post-quantum era.
- Grafana relied on truncated hashes for security, leading to a vulnerability.
- Soatok is not happy with Matrix’s response after disclosing multiple cryptographic vulnerabilities. Their conclusion: Don’t use Matrix.
- Trail of Bits discovered that static initialization vectors (IVs) are used in two popular AES libraries.
- DigiCert is open-sourcing TrustCore, its TLS 1.3 cryptography software development kit for constrained environments.
|
