28
votes
What are the best truly unbeatable E2EE, presumably P2P messaging apps?
My thoughts are that apps can have end-to-end encryption, but if the app on the end is still connected to someone's servers, there's nothing stopping them from pulling the contents of the chat after it's been decrypted on the other end. What options do we have for messaging that don't have this issue? I understand that anything that I can see can still get taken by the OS, etc., but I'm curious about that first step.
There's really no way to prevent an app from stealing content after it has been decrypted -- it has to connect to the internet to be useful, and you realistically won't be able to audit every single connection it makes.
Having a peer-to-peer architecture won't really change that (in fact, it makes auditing all connections even harder because you connect to random strangers), and additionally exposes your IP-address to random other peers in the network.
That said, you might want to look at Simplex.chat. It has a number of favorable properties -- its architecture sits somewhere between a peer-to-peer network and centralized servers. You connect to one of a set of relay servers (that you can self-host too, if you want), and the recipient has to fetch their messages from that same relay server. Channel identities are ephemeral and everything is heavily encrypted to make it very hard to link sender and recipients even if you control the relay server that is being used, though it is still not impossible IIUC.
I'd imagine the simplest form would be to encrypt your messages manually with a PGP key pair, and manually encrypt/decrypt on either end. You could even just use email for this purposes - I seem to recall Thunderbird and Proton Mail having built-in PGP systems but it's not difficult to do manually. You could just send PGP encrypted messages via Whatsapp if you'd like (I get the feeling you'd be banned for doing it on most social media though).
Of course this doesn't solve the issue of someone on the other end reading the decrypted message, but nothing does really. You can attach a password to the encryption key that the user has to type in manually (IIRC, haven't used PGP in a while), which does help, but again if someone knows the password or reads it after decryption then it's not much help either.
Hmm, I wouldn't exactly call this good advice. Yes, pgp encrypted communication via an otherwise unprotected channel such as email would technically be end-to-end encryption, but you'l loose perfect forward secrecy (PFS) - a desirable property that is for example implemented by the signal or matrix protocols. It's better than nothing, but using pgp for a messenger service is by no means an equivalent replacement.
What you usually want to achieve is, that if one secret key is leaked, you won't be able to derive other keys used for previous or future communication from it. With PGP you only have one public-private key pair that's being used repeatedly. If this key is leaked by an attacker, they'll be able to decrypt all past and future communication with it.
A common mechanism to agree on a secret key while maintaining perfect forward secrecy is the Diffie-Hellman protocol. Using (EC)DH you can easily establish a new session key whenever necessary, without a passive MitM being able to derive the exchanged key and no dependency on any earlier key. There's still a long term key required for signing the DH key exchange to verify your communication partner's identity, so that they can't be impersonated by an active MitM, but it'll have no effect on the derived session key.
Now the issue with DH is, that a fresh input is required from each communication partner to securely perform a key exchange and maintain PFS. Hence it's awesome for live communication, such as establishing a TLS connection to some webserver, but some workaround is needed to make it work with the asynchronous nature of messenger services.
This is where for example the signal protocol's double ratchet mechanism comes into play. The signal protocol basically maintains a root key chain, a sender key chain, and a receiver key chain. I'll simplify some details here, but the basic idea is as follows:
As long as secure crypto primitives are used for its imolementation this mechanism is provably secure, and other than PGP ensures PFS.
Now this is the theoretical perspective. It seems to me that OP simply does not trust the client/server implementations, which is much rather a practical issue. If you manage all your keys manually you shift the responsibility for keeping them secure from the application to whatever system you have of managing them. Either way your system could still be compromised on many different levels, so its probably a good idea to use something with individual message keys instead of one long-term key.
In the end its also a question of usability. At some point you have to bring decryption into play if your communication partner wants to read the messages you sent them, and at that moment someone will be able to interfere if they're on the device that does the decryption already. But going as far as keeping the keys in your head and doing all necessary calculations there is just not feasible.
So maybe its simply a question of how much you trust the software you put on your device. As for common messenger plattforms let me tell you this:
So matrix is probably your best bet to when it comes to ensuring the implementation of the protocol does what its suposed to do. And if you wanna go all the way, you can host your own matrix server. You'll also have to invest time into keeping it up to date and running if you decide to do that though.
If you still wanna do the PGP idea, you can of course send inline pgp messages via Matrix as well, but if you go that far I'd say it only makes sense if you don't store the PGP key on your device, but use dedicated security hardware such as a YubiKey.
But at that point https://xkcd.com/538/ may come into play. In the end you can only do so much.
That's a great, obvious, simple solution! Thank you haha
If you do want to go down the PGP+email route you might want to check out delta.chat.
I have no experience with it, just have seen it proposed in similar topics around the web.
One thing to keep in mind with any PGP+email solution is that it lacks forwards secrecy, so if a key is cracked/leaked/etc all previous and future messages will be available to the attacker too.
[Edit: added the following paragraph]
I kept looking around for information and found this comparison, I don't know anything about the author but it gives a nice overview of capabilities that you can use for further research.
Came here to also suggest delta.chat. I also dont use it since signal satisfies my needs.
That's apples to oranges. It's true that a if the client of an E2EE messaging suite yoinks the unencrypted software and sends it somewhere else, that's a way for the underlying message to get out, but that has nothing to do with whether or not there's a server component, and all to do with whether or not you trust the client.
If you don't trust the client, a P2P messaging suite will be just as exploited.
If you're really paranoid, what you can do is simply do the encryption before you send the message yourself. You can exchange keys and use something like openSSL to pre-encrypt your message with your contact. At that point, the security of the channel you use is irrelevant, and since you are the client, effectively, it is as secure as you can trust yourself.
I should add that I have heard that the only truly secure encryption method is the one-time pad: one of the correspondents generates, say a terabyte of randomized bits and saves identical copies on two pieces of physical media that they own and directly control, such as a physical computer that they own in their home ir business and a freshly formatted microSD card. The microSD card is physically delivered to the other correspondent via some secure method. The two correspondents can now exchange perfectly secure messages that cannot be broken, even by a hypothetical future quantum computer.
This is better for text than it is for voice, images, or video, but at 1 TB, you can exchange a lot of compressed video before having to ship another microSD card of randomized bits.
Another implementation I have seen is one's own email server. Although many have pointed out the difficulty of running an email server locally, this is primarily the case for trying to send email to your friend's gmail account. If, however, both parties have email addresses on the same server that one of them owns and controls, then they can exchange messages securely with security as strong as the server's. This could include strong passwords, MFA, IP address whitelisting, fail2ban, and I suppose other methods that I am not aware of. I have seen this done with my own eyes with large companies to handle sensitive information securely: they will only exchange messages with you on their own server with an email address that they assign to you for the duration of that specific conversation. Aside from side-channel attacks, or something like heartbleed, I cannot think of an obvious vulnerability of this method.
I'm not a cryptographic expert but for 1) I believe that while theoretically OTP is unbreakable, any mistake could be fatal. Some cryptographic algorithms, while less unbreakable, include misuse resistant property, such as AES-SIV which allow for key & nonce reuse (which break some property but doesn't completely break down).
I'm not one either, so I'm glad to learn about what some of the disadvantages of OTP encryption. Thanks!
Not that it matters, but you're slightly mistaken about the one-time pad. It is a good theoretical solution, though.
Indeed! Can you specify where I am mistaken about the one-time-pad? What you wrote reflects my current understanding and the intent of my post. I even found a nice thesis from a few years back, Open source OTP voice encryption in microcontroller.
Actually, I was mistaken. For some reason, I was thinking that being longer than the plaintext would be a security issue, but that's only because I was inferring that you were suggesting to use a one-time pad more than once, which, I highly suspect, you were not saying.
The fabled "two-time pad". I wouldn't be surprised if I did get things wrong. I think Cryptonomicon by Neal Stephenson was my first exposure to the one-time pad, but that was in the WWII, physical pieces of paper embodiment (if it also discussed a modern implementation, then I missed that). My first exposure to a modern implementation was in Vernor Vinge's A Fire upon the Deep, which involved physically transporting large amounts of random binary data, which, in a way, also made me aware that asymmetric encryption was vulnerable to attack in a way that symmetric key encryption wasn't.
Given that my knowledge of the one-time pad is derived primarily from casual reading science fiction, then I should not be surprised if there were gaps in my understanding. I think a symmetric key text messaging protocol and app would be super interesting to see and use, but, unfortunately probably doesn't exist and probably never will.
If anyone is interested in making something like this, I would really enjoy the opportunity to bring my decade of on-again-off-again Python programming experience to help.
We could always make a Tildes messaging app designed solely with simplicity, confidentiality, and integrity in mind while externalizing availability.
Given that my knowledge is me (mis)reading your comment, saying "I think I've heard of that," reading the Wikipedia page and remembering that I'd learned about it before but forgotten much of what I'd learned, I'd trust you over me.
Surely the solution here is any open source app? Then so long as you compile it yourself you (or someone you trust) can check it does not do anything that you don’t want to happen.
Yes, but I was asking if one is better than others.
In that case, generally Signal is the most widely-respected solution here. In theory, you can even build the client yourself, if you'd like, since it is open source.
You will see arguments online about Signal, as they've had some controversies. The main two being that they added their own cryptocurrency (which is barely visible in the app these days, you have to go digging in the settings to find it), and how they added it (they paused publishing their server code for months until the feature was complete). These are, at best, circumstancial evidence to lower trust in them, but absolutely not indications that anything you care about in this post is compromised.
However, of the consumer-focused messaging apps, Signal by far has the best cryptography, track record, and usability. Personally, I would recommend it over Whatsapp, Threema, Telegram, definitely over PGP email, and even over Matrix (if security is your main concern).
I will add a few other notes for context:
The cryptocurrency doesn't use proof-of-work, from what I remember, so it's environmental impact should be negligible.
Signal has publicly responded to warrants requesting user data multiple times, indicating that they cannot provide most information about a user.
Again, the code is open source, and people do regularly audit it. You can also build it yourself, though of course that is more involved. The app is even reproducible, so you can prove that the one on the Play store is the exact same as the one you built locally from source code: https://signal.org/blog/reproducible-android/
I knew people always talk about Signal, but looking into it, it's good to see that the app is made to not trust the servers, so even if the server side were to try to pull something from the app, the app wouldn't do it. My concern is mainly with trusting the app to not decrypt and then give the plaintext to the server given the political climate and that you never know what could happen going forward (e.g., Google/Facebook say "yeah, I don't mind telling you what that dude said," or worse, "yeah, we can pull what everybody has ever said and analyze it." So default Signal is good for some things, but it seems building it yourself is the only way to make sure they don't update the app in the future without me knowing.
This is not a threat model you should care about. If Signal's build servers are compromised and they ship an update that decrypts messages locally and sends them to some server, a lot more shit is going to go down. Provided you are not a journalist in Eastern Europe or the Middle East, or a whistleblower of any kind, you have nothing to worry about.
You're most likely right. I know my position, how it may evolve, and what my concerns are. I don't expect anything to happen, at least not for a while. I just want to have a plan and I've been concerned about sharing certain thoughts given the above.
You may already know this, but a more formal way of thinking about this is "threat modelling". In particular, that helps you think holistically about your situation, your goals, potential plans, and various tradeoffs. A malicious e2ee client sending clear text off of your device is definitely a valid threat! But there are also plenty of other threats, and it's not immediately clear how to rank / address all of them. For instance, others in this thread have mentioned manually encrypting your own messages, but that comes with lots of risks too. (What if you forget or get lazy? What if you do it wrong? What if the metadata is just as important as the data? What if it doesn't give you desirable properties like perfect-forward secrecy?)
The EFF (which is a American digital civil liberties nonprofit) has a Surveillance Self-Defense site, which helps you think through these things. Specifically, their page on threat modelling might be helpful here. It also has guides to lots of other settings, apps, and habits that can help you harden your security posture.
I disagree with @petrichor that it's an attack you shouldn't be worried about. I think you SHOULD be worried about the potential of that from a few places. iMessage's history being stored I think was an issue, someone else mentioning WhatsApp's history optionally being stored in Google Drive unencrypted. Those are basically versions of the vulnerability we're discussing.
IMO (as not a super security nerd) is that Signal is your best option. I have a large amount of trust that the people running it care about secure messaging, the platform is fairly common, and it's simple to use which is important when trying to get other people to use it.
Again IMO... part of that plan should be to start moving people to your chosen platform now, not after shit hits the fan. If your communications are insecure today then they could be used against you tomorrow.
Side note. Signal has disappearing messages as an option. Use that so that you avoid the attack of someone just forcing you to unlock your phone.
Appreciate it. I've already set up chats with disappearing messages in Signal with certain people. Signal gets bonus points for being quantum resistant, so in a worst case scenario with no "insider threats" ruining things, that should provide at least 25 years of privacy, according to current estimates (which I don't trust given that I don't trust any estimated tech timelines).
Quantum resistance is also not a threat model you should really care about. There is enough classical cryptography out there that if quantum computers ever turn out to do anything useful at all (I am skeptical), again, there's a whole lot more to worry about.
I'm just going to say you really don't know what my threat model is but it's not just simple privacy protection or paranoia. I generally operate on the assumption that if thing x breaks, I'll be worried about something else much more, but some things still need to be protected even when everything else is broken.
I think to clarify on this: Signal shipping compromised builds would be extremely obvious immediately because they are open source and have reproducible builds. If they push malicious code, the community will notice. If their build servers + keys are compromised and someone ships an update that doesn't match with the source, the community will notice. That makes this sort of attack something you do not need to worry about -- in the specific case of Signal.
iMessage and WhatsApp are different due to their clients being closed-source, which renders any claims of end-to-end-encryption meaningless. Total marketing garbage. They can hire audit teams to say whatever, of course, but even if you trust them (don't - no reason to) there's nothing to say what changes in the future: like, say, their clients being stealthily updated to back up messaging history unencrypted.
This is particularly evident with Apple. For years, they've waxed and whined about being a company that puts privacy first. But this is meaningless, because a corporation's only loyalty is to profit, and so when faced with handing over all UK user data or losing the UK market they immediately rolled over. Actual guarantees (like what open source clients + reproducible builds get you) is how you avoid these threat cases: if Signal does get compromised in the future for whatever reason it will be obvious immediately.
I agree with your criteria for messengers, by the way. Usability is super important.
Re-reading your comment, I have no idea what I thought you said before, but I must have lost the plot.
Paper messages, cypher is agreed upon previously, burn after reading if you want to be the most secure. But even with the most secure systems, someone who wants to find something out probably will through the path of least resistance, and more often than not, it involves a $5 wrench.
I was wondering about that. From everything I understand about encryption (probably slightly more than most high schoolers, probably slightly less than most university students) it seems like everyone is talking about encryption to talk in plaintext, but I feel like a simple cypher can completely break any attempts at reading your messages, right? Especially if it’s a cypher that involves looking up an external source, like a dictionary or the bible or a novel or something?
Just to make sure...
Do you suggest to send encrypted messages electronically that unencrypt into gibberish that you then decipher (preferably analogously) with a previously agreed upon cypher (like a book)?
I like it!
Yeah, a book or maybe something like Library of Babel? https://libraryofbabel.info/bookmark.cgi?xwtt.rjw311
Something that actually involves the bible or a book is going to be low entropy enough that codebreakers can trivially break the code.
But the logical extension of cyphers is the One-Time Pad. And as lot as your OTP is truly random, then it is as unbreakable as it is random.
The issue is that in practice, it's obnoxious to use. How do you exchange this OTP with the other party? The beauty of something like Diffie-Helman is that you can have two parties, with no other way to communicate with each other except an unsecure, public channel, and they can end up with two secrets that they can use with AES or another symmetric encryption scheme that no one else can use, despite the fact that they were talking on a public channel the whole time.
Yeah I meant the bible as an illustrative example, I feel like it’s too widely known to be very secure. But the idea behind it would be that a person who decrypted the message only ever sees a bunch of numbers, so actual non-automated effort would be required to start attempting to identify the cypher, which might not be robust against a dedicated team focussing their efforts on you, but certainly gets in the way of automated mass surveillance.
Before your comment I wasn’t sure what a one time pad actually was, but Wikipedia has given me a useful understanding, and yeah that seems pretty convincing to me, but also the effort in creating two copies of truly random keys seems considerably above anything I’d ever need given I don’t intend to be targeted by actors with state-level resources. But super cool to learn about it, thank you!
Along the same vein, you should read about number stations