Service to expose all encrypted messages its users sent. How protected would this data be?

Question

I have recently started a new side project for an open-source messaging system with end-to-end encryption.

My key idea with this project is that everything should be as transparent as possible, with the server only being an intermediary - a repository for encrypted messages that can be accessed by anyone but can only be decrypted by their intended recipients, who will keep their private keys safe locally.

My choice for encryption is PGP as my knowledge is that there are no known attacks that can crack it; that it is protected against attacks where both the plaintext and its encrypted version are known and that using initialization vectors you can make sure two instances of the same content don't produce the same encrypted output.

However, allowing everyone to access all encrypted messages seems risky because:

• There are no known attacks for the time being but that can change in the future
• Brute-forcing would take ages with current hardware but hardware is only going to improve
• Quantum computers will probably become a thing in the future

I really don't want the server to handle authentication and sessions as I want to treat it as something the user can't really trust (with recent history showing it's often just a matter of time and interest whether a server will get compromised). I also want to provide users with more anonymity and privacy - if the server can't know who a user really is (because it won't know if they could decrypt the messages they accessed), an attacker who has gained control over it and is monitoring its connections can't either, at least not for sure.

My question is, is it reasonable to allow everyone to access all messages? Are the points I mentioned about possible attacks in time reasonable? Is this improved "privacy and anonymity" really not a good trade-off for the possibility messages would eventually be cracked?

Answer 1

To answer your primary question: Making encrypted messages accessible to everyone can be a security risk. A messaging system is typically asynchronous (meaning that you can send a message to someone that is currently offline), which makes it very difficult to provide perfect forward secrecy (great article how TextSecure solves this issue here). So an attacker with great storage capabilities (for example with a huge datacenter in Utah) could simply collect all messages that flow through your server and store them. Whenever the PGP private key of a user gets compromised, the attacker can simply go back to the recorded messages and decrypt all the messages that user received.

However, you also mention that you are assuming an adversary that can compromise the server itself. In that scenario, it doesn't matter whether or not every user can access all messages. I think it is important to first understand the goals of your messaging system as well as the different security building blocks you want to use.

Security Goals

1. Receiver Anonymity: By making the server a public repository for encrypted messages, you are basically creating a broadcast channel where everyone can potentially receive the message but only the intended receiver(s) can decrypt it. There exists a great body of research around receiver anonymity (e.g., this), but I am not sure whether this is actually the right approach to building your system. The problem that any kind of broadcast channel solution has is that each party has to attempt the decryption of each message, which does not scale very well (ironically, the receiver anonymity increases with the amount of participants in the system). So regardless of whether or not the exposure of the encrypted messages to all participants poses a security risk from a cryptographic standpoint, I would not recommend this approach for a messaging system due to performance reasons.

2. Privacy: Using PGP will indeed provide confidentiality for your messages. However, it also requires the participants of your messaging system to have an authentic channel to retrieve each other's public keys. This cannot be the server itself, since you are assuming a potentially malicious/ compromised server setting. Threema thought of a good workaround for this problem where the server distributes the public keys but the user can verify the key's fingerprint via an out-of-band method (phone call, scanning the QR code, ...). Even if a malicious server would replace the public key of the receiver with its own, the sender could spot this by verifying the fingerprint.

Existing Building Blocks

1. Mixes: You can read about mix networks here. You basically achieve that a passive attacker can learn the identity of all sender and receiver but cannot link them together. This is the same level of anonymity as in your setting, as the malicious server knows who is connecting but does not learn which messages can be read by whom.

Implementation Recommendations

Have a look at XMPP/ Jabber. There exist great extensions for the protocol to offer end-to-end encryption and even OTR messaging.