Encrypted Apps Comparison

Encrypted Apps Comparison

Types of Applications

Traditional Web Application provides no confidentiality promise, as all the data is readily accessible to the provider at all times. There is a lot of encryption that takes place in a traditional web application, for example the HTTPS network connection is encrypted and often the server filesystem is encrypted. However, we exclude this type of encryption from the discussion here, because there is a single key that is used for all users, instead of there being distinct keys for each user.

Encryption in the Browser web application is one where the encryption keys are not seen by the server and all encryption & decryption takes place on the client-side in the user’s browser. Proton, CryptPad, and Mega are examples of this type of application.

Encryption on the Server web application is one where the encryption keys are only seen by the server and not the browser. Raft is an example of this type of application.

Installed E2EE App is an application that is locally installed on the user’s device. Only the local app has access to the encryption keys and all encryption and decryption takes place within the app. This type of app is often called “end-to-end encryption”. Signal and Anytype are examples of this type of application. No “Encryption in the Browser” app is true E2EE unless it is installed via a web browser extension, in which case it just becomes an “Installed E2EE” app.

Threats

Consider the four primary threats faced by apps that prioritize the privacy of user data:

read stored data: Sensitive data stored at rest is read by someone the user does not want to have access.
read live data: Sensitive data is read “over the wire” live in memory or the network.
privilege escalation: Someone gains permissions they should not. For example, when a user with view-only access is able to write.
key compromise: Encryption keys are obtained by the attacker in order to read stored data or read live data.

These threats are not included in the following analysis because they are mostly a concern for p2p E2EE client apps: data loss, impersonation, metadata analysis.

Potential Attack Vectors:

man-in-the-middle read-only: The attacker is able to intercept and read the encrypted web connection between the user’s browser and the web application. This is an extremely difficult attack, which typically requires a valid & signed imposter TLS certificate signed by a trusted root Certificate Authority. However, potentially this type of attack could be achieved with a court-ordered wiretap order for ongoing data collection.
man-in-the-middle read-write: Sometimes the MiTM attacker is able to modify as well as read encrypted network traffic. This is even more difficult than a read-only MiTM attack.
client device static compromise: Sometimes an attacker is able to unlock a device and read the filesystem contents (either from a powered on or powered off state). In many cases, such as law enforcement forensics, this is a common and easy attack (unless the device is one of a few models with good security). This attack requires physical access to the device.
client device live compromise: Often, attackers are able to install malware on the client device. The most common form of this is a targeted spear-phishing attack, where the user is tricked into installing malware, or if the attacker installs the malware themselves. On very rare occasions, a live device compromise is achieved by an attacker using an unpatched security vulnerability in the operating system or web browser. A live device compromise might result in a client code modified or man-in-the-middle read-write.
client code modified: The web applications “frontend” javascript code (the part that runs in the browser) may be vulnerable to allow malicious javascript to be run in the browser. Alternately, the user may be running an out-of-date browser with known vulnerabilities that are unpatched. In the case of a client app, the app might be malware or infected with a virus.
client code bug: The client app might have a bug that leaks sensitive information or allows for script injection.
server code modified: The app backend code (what runs on the server) is potentially also vulnerable to supply chain attacks or to an attacker who has write access to modify the server app code.
server code bug: A bug in the server code could potentially allow an attacker to launch any of the other attack vectors, in the worst case scenario.
server assets modified: The attacker might modify the library dependencies used to build the frontend code (supply chain attack) or the attacker might have access to the server and modify the static assets.
server memory compromise: An attacker with root access on the server can read the memory of the server app (but not write).
server database compromise: The database is compromised if an attacker can read potentially sensitive stored information. Examples include an attacker with read access to the server, or an attacker with read access to server backups, or an attacker who can compel the service provider to turn over the stored database (e.g. a court-ordered subpoena).

Comparison Tables

Data Privacy By App Type

Attack Vector	Server	Browser	Installed
Attack Vector	Encrypted App Type
`man-in-the-middle read-only`	bad	good	good
`man-in-the-middle read-write`	bad	bad	good
`client device static compromise`	good	good	varies
`client device live compromise`	session	bad	bad
`client code modified`	session	bad	bad
`client code bug`	good	bad	bad
`server code modified`	bad	bad	good
`server code bug`	bad	bad	good
`server assets modified`	session	bad	—
`server memory compromise`	bad	good	good
`server database compromise`	good	good	good

Outcomes:

Good: Highly resistant to loss of data privacy (no read stored data, no read live data, no privilege escalation, no key compromise)
Session: The encryption key remains secure (no key compromise), but the attacker can view data over the wire as the user views it (read live data).
Bad: Vulnerable to this attack vector, possible catastrophic compromise of all encrypted data.

Key Security By Authentication Type

For encrypted apps, the generation of encryption keys and the authentication process are tightly coupled.

Vector	PRF	SRP	KDF
Vector	Authentication + Key Generation
`man-in-the-middle read-only`	bad	good	good
`man-in-the-middle read-write`	bad	bad	good
`client device static compromise`	good	good	bad
`client device live compromise`	session	bad	bad
`client app modified`	session	bad	bad
`client app bug`	good	bad	bad
`server app modified`	bad	bad	good
`server app bug`	bad	bad	good
`server assets modified`	session	bad	—
`server memory compromise`	bad	good	good
`server database compromise`	good	bad	good

Types of authentication + key generation:

PRF (Webauthn pseudo-random function extension): Encryption keys are generated during authentication. One half the key material lives on the server, and one half lives with the security key or passkey. There is no password. If the seed is rotated, a MiTM cannot replay the exchange to reproduce the authentication or obtain the keys. (If PRF is used to generate keys client-side, it takes on more of the properties of SRP). PRF is vulnerable if the attacker has both compromised the server database and can MiTM network traffic.
SRP (Secure Remote Password): The frontend javascript app authenticates with the server using a zero-knowledge proof. A MiTM never sees the password. The password used in SRP is then typically used to generate encryption keys using some KDF run in the browser. SRP can expose the password if the database is compromised because it is vulnerable to brute force attacks that try many password possibilities.
KDF (Key Derivation Function): The password is run through a function to generate the key. The function is expensive in terms of CPU or memory to thwart brute force attacks against many password possibilities. Once the key has been generated, typically authentication happens by the server issuing a challenge and the client signing it with a public key. Typically, measures are taken to prevent replay attacks. This method, when used by an installed client app, usually does not have strong resistance to client device compromise (but could be engineered to be by putting part of the seed used to generate the key on the server).

Outcomes:

Good: Highly resistant to authentication attacks of this type and the key material is likely to remain secure.
Session: The encryption keys and stored data remain secure, but the attacker can read data over the wire as the user views it. The session cannot be hijacked (session cookies can be set HttpOnly).
Bad: Vulnerable to this attack vector, possible catastrophic leakage of encryption keys and confidential data.

Conclusion

In general, installed apps place trust on the client device and web applications (of any variety) place trust on the server. Because a compromised client end-point can also compromise the browser or network, an ongoing device compromise can be catastrophic under any approach.

The distinction for web applications:

When the encryption takes place in the browser, the app is resistant to read-only MiTM attacks and read-only server memory attacks.
When the encryption takes place on the server, an end-point compromise exposes whatever data the user sees for that login session (often very bad, but potentially less bad than full key compromise that would happen in browser-based encryption).

Not All Attack Vectors Are Equal

In practice, some of these attack vector are very difficult to achieve or much easier to defend against.

Which ones do we really care about?

client device static compromise: Routine forensic analysis tools can compromise most end-user devices. This is very common.
server database compromise: Routine court-ordered subpoenas can force a provider to turn over stored data. This is very common.

All methods of per-user encryption perform well against server database compromise. Most web apps perform well against client device static compromise. However, there are a few exceptions:

Some “Encryption in the Browser” apps use SRP for authentication (e.g. Proton). This makes the application’s encryption keys vulnerable to server database compromise.
Some apps (web and installed) store sensitive data locally on the client device, either in cleartext or encrypted using low entropy keys, making them vulnerable to client device static compromise.
All apps are vulnerable if a client device static compromise leads to the compromise of the user’s password manager and the password manager is used in the authentication process.

What about the other attack vectors? There is no defense if an attacker has installed malware with superuser privileges to fully compromise the user’s device. Although malware does not often lead to superuser privileges for the attacker, when it does happen the best you can hope for is to limit the disclosure to information the user views during their login session.

MiTM attacks are difficult to perform, usually easily detected, and rarely occur. SRP performs well against man-in-the-middle read-only, but this minor benefit is outweighed by its poor protection against the more common server database compromise.

Attacks on server infrastructure are common, but much easier to defend against than other attacks. By following best practices, server administrators can create very secure infrastructure. In contrast, there is no practical way to harden the end-point devices of everyone in an organization.

App Type	Advantages	Disadvantages
Browser Encryption Web App	Nothing to install; Can sometimes be packaged as an installable E2EE app	Server must still be trusted; Very complex, even for basic apps
Server Encryption Web App	Nothing to install; Very simple to write complicated apps	Server must still be trusted;
Installed E2EE App	Trust only your client device	Requires installation and updates; Typically vulnerable to static device compromise; Very complex, even for basic apps

Raft

The thesis that motivates the design of Raft is the following: It is much easier to properly harden the security of a single server than it is to harden the security of thousands of end-user client devices. The primary attack vectors we need to worry about are server database compromise and client device static compromise because these are the most common and easy to perform. The structural weakpoint of encryption-on-the-server, that a compromised privileged account on the server can read memory or modify code, is a risk that can be effectively mitigated against, both in terms of best practices for server security and choosing providers with incentives that align with your own.

Additionally, Raft’s use of PRF makes its key generation and management much more robust and user friendly. PRF is a new and preferred method of creating encryption keys (for any type of web app), because the keys generated are very random, do not depend on user defined passwords, depend on combining secrets from the server and the client, and are highly resistant to offline brute force attacks attempting to derive the encryption keys. When performed using a physical security key, the client secret used is very strongly protected. Best of all, the user does not need to manage a password.

Raft could be modified to use encryption in the browser. The analysis presented here suggests this change would make the app slower to load, more complicated to write, and would only improve security against rare and unlikely attacks.

Attack Details

Modifying Javascript

When a webapp uses browser-based encryption, the encryption can be defeated by modifying the javascript sent to the browser (or adding additional javascript loaded by the browser).

In order to do this, the attacker must modify the server code to send modified javascript, exploit a bug in the client code that allows for javascript injection, or modify the client app as it is sent to the browser.

In all these areas, a browser-based encryption provides equal or lesser architectural resistant to attacks than a server-based encryption application provides.

Browser-based encryption does perform better in two cases: A read-only MiTM attack and when an attacker has gained read-only access to the server’s memory. However, these are not common attacks and are very difficult to perform.

Supply Chain Attacks

All applications are vulnerable to supply chain attacks, where an attacker compromises a dependency or tool in the development pipeline rather than targeting the application directly. This is particularly dangerous in modern JavaScript ecosystems (including and especially browser-based encrypted apps) because a typical javascript app may depend on thousands of open-source packages. An attacker who gains control of a popular package (either by compromising a maintainer’s account, acquiring the package through domain takeover, or inserting malicious code via a dependency update) can inject backdoors, cryptocurrency miners, or credential-stealing code that will be automatically included in every application that updates or installs that dependency.

High-profile supply chain incidents include: 2018 event-stream compromise, where a maintainer unwittingly handed control of a popular package to an attacker who added a Bitcoin-stealing dependency; 2021 Codecov breach, where a modified bash uploader script exposed thousands of customers’ CI/CD environments.

Man-in-the-Middle Attacks against TLS

A Man-in-the-Middle (MiTM) attack against TLS occurs when an attacker positions themselves between a client and server, creating two separate encrypted connections while impersonating the legitimate server. To succeed without triggering browser warnings, the attacker must present a TLS certificate signed by a Certificate Authority that is trusted by the client.

How MiTM Attacks Are Achieved

A successful read-write MiTM attack requires two things:

Network Position: The attacker must have access to modify the network traffic between client and server.
Trusted TLS Certificate: The attacker must have a private key for a TLS certificate that the client will trust.

A successful read-only MiTM attack requires two things:

Network Position: The attacker must have access to read the network traffic between client and server.
TLS Private Key: The attacker must have a private key for a TLS certificate that the server uses.

Achieving Network Position

Attackers can perform BGP hijacking (announcing false internet routing tables to reroute traffic through their infrastructure). For example, as demonstrated in the 2018 MyEtherWallet attack that redirected traffic to steal $150,000 in cryptocurrency.

Nation-state actors can tap undersea cables: GCHQ’s TEMPORA program reportedly tapped over 200 cables, an operation requiring hundreds of millions of dollars.

Client device compromise: Malware installed on a client device can potentially gain control of the operation systems network stack to perform MiTM locally on the device itself.

Achieving TLS Trust

If an attacker steals a CA’s private signing key, they can forge valid certificates for any domain. When a victim connects, the attacker presents this forged certificate, and the browser shows the secure padlock because the certificate is correctly signed by a trusted CA. In 2011, the Dutch CA DigiNotar was hacked, and fraudulent certificates for *.google.com were issued and used to attack users in Iran. The breach destroyed DigiNotar—all major browsers revoked its root certificate, and the company went bankrupt.

Nation-states can mandate the use of their own CA. In 2019, Kazakhstan required all citizens to install a government-issued root CA certificate to access the internet, allowing state interception of TLS connections to hundreds of domains including Google, Facebook, and YouTube.

Nation-states can order that a provider give law enforcement the private TLS key used by the server. The US government obtained a search warrant in 2013 for the service provider Lavabit to hand over its private SSL keys. Surrendering the keys would expose all customers, not just the target (who was Edward Snowden). The courts ordered compliance under threat of $5,000 daily fines. On August 8, 2013, Lavabit turned over the keys and simultaneously shut down.

Additionally, nation-states can order a CA operating in their jurisdiction to generate a fraudulent certificate.

Client-side compromise is another vector: malware or malicious applications installing a fake root CA certificate onto a user’s device enables silent interception of all TLS traffic from that device with no warnings.

Implementation flaws in TLS libraries can bypass authentication entirely. In 2025, a high-severity vulnerability (CVE-2025-27809) was discovered in Mbed TLS, affecting all versions up to 3.6.2. If an application failed to call a specific hostname verification function, any server with a certificate signed by a trusted CA could impersonate any other server.

As part of the Snowden leaks, an NSA slide contained the phrase “SSL added and removed here! :-)” in reference to how the agency had systematically stripped TLS encryption at specific backbone points (targeting the internal networks of large companies like Google and Microsoft). Due to technical changes made after this revelation, this type of backbone attack is likely no longer possible, although we don’t have recent leaks to confirm this.

How Common Are MiTM Attacks?

Despite their theoretical severity, MiTM attacks are relatively rare in practice. For most organizations, the risk of a stolen private key being used for a MiTM attack is vanishingly small.

What actually compromises most TLS connections is endpoint compromise, not network interception. When attackers compromise a device through malware or phishing, they can install whatever root certificates they want, rendering all TLS protections irrelevant.

The TLS/CA ecosystem has proven resilient against large-scale MiTM attacks because an attacker must forge certificates, get in the right network position to use them, and remain undetected.

Detecting MiTM Attacks

There are two systems for detecting MiTM attacks: Certificate Transparency and TLS Observatory. Both systems detect certificate-based MiTM attacks by exposing fraudulent certificates after issuance. Neither prevents attacks in real time.

Certificate Transparency (CT): CT mandates that all CAs publicly log every certificate they issue in append-only logs. Domain owners monitor these logs for certificates they didn’t request. A fraudulent certificate becomes visible in logs within hours of issuance. Modern browsers also require proof of logging (SCTs) during TLS handshakes (typically embedded in the TLS certificate), forcing attackers to either expose their fraudulent certificate or have it rejected by browsers.

TLS Observatory: The observatory aggregates certificates seen from millions of network vantage points. It builds a baseline of legitimate certificates for each domain. When a user presents a certificate that differs from the global baseline–for example, one signed by a local corporate CA instead of the domain’s public CA–the Observatory flags the anomaly, indicating a potential MiTM via an intercepting proxy.

CT provides cryptographic audit trails and is mandatory browser infrastructure. The Observatory provides statistical anomaly detection based on crowdsourced data.

Local Device Compromise

Installed App

An “Installed E2EE” app places trust on the local device. Sadly, most devices can be readily cracked by law enforcement, although the cost of this varies by device and law enforcement agency.

Some installed E2EE apps mitigate against a loss of confidentiality caused by a compromised client device by encrypting their local storage using a key generated from a passphrase when the app is run (e.g. Briar, Anytype, etc), although many do not (e.g. Signal). This approach can greatly improve the confidentiality of local data, although these apps are usually still vulnerable to unlimited brute force attacks and thus place their security on the ability of the user to memorize a long unique random password (something humans have proven particularly incapable of doing, in aggregate).

A potential solution to this problem, one not yet implemented by any app, is to split responsibility for generating the key between the local device and a remote service that can force rate limiting (Signal works this way for restoring backups).

Web App

An attacker who has installed a “live” compromise on the client device can sometimes be able to modify the behavior of the web applications that the browser runs by injecting malicious javascript, reading the value of cookies from the filesystem, installing fraudulent Certificate Authorities, or reading memory on the device.

To do any of these things typically requires a full compromise where the attacker has superuser permissions.

Intentional Backdoor

The service provider or app developer can install a “backdoor” into their own code for the purpose of undermining the advertised security properties of the application.

This could be the result of a malicious staff member or in order to comply with a court order. For example, to comply with a 2007 Canadian court order, Hushmail added a backdoor into their browser-side encryption app that targeted specific users and exfiltrated their password.

Law Enforcement

When it comes to data privacy threats from law enforcement, we must distinguish by type:

Mass surveillance: Large scale data gathering of the population or communities as a whole is largely outsourced by governments to private companies, such as data brokers, or data aggregators like Palantir. In some cases, the NSA directly ingests and stores surveillance data from large providers, as is the case with SMS metadata. Mass surveillance is a serious threat to social movements. All privacy focused tools will provide effective protection from mass surveillance for the data contained in those apps, but data brokers depend on advertising trackers and companies selling the data you give them.
Administrative subpoena: Law enforcement can, and often do, issue their own subpoenas for stored communication. Lately, the large providers have begun to readily comply with these subpoenas, even though they are under no legal obligation to do so.
Court-ordered subpoena: When a judge signs off on a subpoena, any US entity served with this subpoena is required to furnish the requested stored information to law enforcement if they are able to do so. If a service provider is not able to do so, as in the case with stored data stored encrypted using a user-generated key, then the provider can simply reply that they don’t have the requested data.
Court-ordered wiretap: When a judge issues a wiretap order it covers capture and reporting of ongoing data transmission. If the provider is able to perform this capability, they are required to do so. If the provider’s technical architecture does not make this possible, the provider is not under any requirement to rewrite their software simply to facilitate live interception. This protection against being forced to redesign software is explicitly written into the law governing voice communication wiretaps (CALEA), but is also current jurisprudence regarding digital interception generally.
Physical possession by law enforcement: When law enforcement has physical possession of a user’s device they will routinely use forensic tools to extract and archive all the information stored on the device. Except for newer devices from Apple or Google, nearly all mobile devices can be cracked by forensic tools without much effort. Because our devices hold the key to our entire digital lives, law enforcement is highly motivated to direct their effort toward obtaining these devices.

A locally installed E2EE app is particularly resistant to the first four threats, but typically vulnerable to the device being seized, an increasingly common occurrence. If you have a group of 100 people, all it takes is one person having their device taken for the group’s entire history to be exposed.

Web-based encryption applications are often (but not always) resistant to confidentiality compromise that originates with a device seizure. These applications (both client-side encryption and server-side encryption) also provide strong resistance to subpoenas, so long as the app encrypts user data in a manner where the provider does not have ready access to the key necessary to read that user data.

Web-based encryption applications are potentially weak against wiretap orders, in that it is technically possible to redesign a system to facilitate interception, although current US law does not require this. However, it is possible in the future that a US court may find a provider is under obligation to implement a feature that allows for real time collection of a web application’s active sessions.

Offline attacks against Secure Remote Password

Some encrypted web application such as Proton use a method of authentication called Secure Remote Password. Traditionally with password authentication, the client sends the server the cleartext password, the server computes a digest from the password and saves the digest. In contrast, SRP is designed so that the server never knows the cleartext password and the client and server are still able to authenticate using a password even if there is a third party listening to the exchange.

SRP is very clever and solves a very specific problem. However, SRP has a major structural flaw: it is NOT designed to be resistance to offline brute force attacks run by an attacker with access to the authentication database. This is the attack that traditional password hashing is designed to prevent. Digest algorithms such as bcrypt (CPU hard) and argon2 (memory hard) are constructed so that each attempt to guess a password is very expensive, making it impracticable to throw a lot of processing power at the problem of cracking a password.

SRP, in contrast, is extremely weak to an offline brute force attack by an attacker with access to the authentication database, by a magnitude of several thousand in comparison to bcrypt (the actual depends on the parameters chosen in the SRP implementation). This means that an attacker can probably obtain the cleartext password in a under a day with minimal computational power.

The result is that SRP, while great for preventing a man-in-the-middle from seeing the password, is absolutely terrible at preventing law enforcement from issuing a subpoena and running a little script to obtain the cleartext password.

The problem is that once the attacker has the cleartext password in an encrypted web application that uses SRP, the attacker can then also generate the private key that is used to encrypt the user’s confidential storage.

An browser encryption web app that uses SRP is potentially an open book for law enforcement.

Caching

As a design choice, many applications loaded in a web browser will aggressively cache data to the user’s local device. Even many apps that use encryption in client-side javascript will store large amounts of data in the clear using the browser’s local storage facility (or if not in the clear, then encrypted using low entropy keys).

When a web application operates in this manner, it becomes highly vulnerable to static device compromise or seizure. In contrast, Raft is designed to store nothing on the client device.

Other mitigations

Although rarely done, an E2EE webapp that uses CORS can load javascript from one service and load data from another, allowing the user to trust the javascript provider but not the data provider. This approach, however, does not diminished in any way the degree to which the end-user must trust the javascript provider.