That's a "great" idea considering the recent legal developments in the EU, which OpenPGP, as bad as it is, doesn't suffer from. It would be great if the author updated his advice into something more future-proof.
If you want a suggestion for secure messaging, it's Signal/WhatsApp. If you want to LARP at security with a handful of other folks, GPG is a fine way to do that.
The available open-source options come nowhere close to the messaging security that Signal/Whatsapp provide. So you're left with either "find a way to access Signal after they pull out of whatever region has criminalized them operating with a backdoor on comms" or "pick any option that doesn't actually have strong messaging security".
Eh?
There are alternatives, try Ricochet (Refresh) or Cwtch.
Which jurisdiction are you on about? [1] Pick your poison.
For example, UK has a law forcing suspects to cooperate. This law has been used to convict suspects who weren't cooperating.
NL does not, but police can use force to have a suspect unlock a device using finger or face.
The answer is not to live with it, but become politically active to try to support your principles. No software can save you from an authoritarian government - you can let that fantasy die.
And that's even if you are innocent on the underlying charge or search.
Encryption in this political climate, is a pick your poison.
- Either you go to jail for years but you know your gov and other actors has no access to your data.
- or you store on remote/proprietary apps, stay free, but your gov or other actors may or may not have access to it.
There are many reasons, but one of them is that for the overwhelming majority of humans on the planet, their apps aren't being compiled from source on their device. So since you have to account for the fact that the app in the App Store may not be what's in some git repo, you may as well just start with the compiled/distributed app.
Signal and WhatsApp do not belong in the same sentence together. One's open source software developed and distributed by a nonprofit foundation with a lengthy history of preserving and advancing accessible, trustworthy, verifiable encrypted calling and messaging going back to TextSecure and RedPhone, the other's a piece of proprietary software developed and distributed by a for-profit corporation whose entire business model is bulk harvesting of user data, with a lengthy history of misleading and manipulating their own users and distributing user data (including message contents) to shady data brokers and intelligence agencies.
To imply these two offer even a semblance of equivalent privacy expectations is misguided, to put it generously.
The preceding comment is saying that source security is insufficient, not that transparency is irrelevant.
Both you and the preceding commenter are correct that just running binaries signed and distributed by Alphabet (Google) and/or Apple presents room for additional risks beyond those observable in the source code, but the solution to this problem isn't to say "and therefore source availability doesn't matter at all for anyone", it's to choose to build from source or to obtain and install APKs built and signed by the developers, such as via Accrescent or Obtanium (pulls directly from github, gitlab, etc releases).
There's a known-good path. Most people do not take the known-good path. Their choice to do so does not invalidate or eliminate the desirable properties of known-good path (verifiability, trustworthiness).
I genuinely do not understand the argument you and the other user are making. It reads to me like an argument that goes "Yes, there's a known, accurate, and publicly documented recipe to produce a cure for cancer, but it requires prerequisite knowledge to understand that most people lack, and it's burdensome to follow the recipe, so most people just buy their vials from the untrustworthy CancerCureCorporation, who has the ability to give customers a modified formula that keeps them sick rather than giving them the actual cure, and almost nobody makes the cure themselves without going through this untrustworthy but ultimately optional intermediary, so the public documentation of the cure doesn't matter at all, and there's no discernable difference between having the cure recipe and not having the cure recipe."
Thankfully, I didn’t say that.
The population of users who have a verifiable path from an open source repo to an app on their device is a rounding error in the set of humans using messaging apps.
You raised concerns about lack of source availability, and I’ve been consistent in my replies that source availability is not the way that somebody wants secure messaging is going to know they’re getting it. They’re going to get it because they’re using a popular platform with robust primitives, whose compiled/distributed apps receive constant scrutiny from security researchers.
Signal and WhatsApp are that. Concerns about Meta’s other work are just noise, in part because analysis of the WhatsApp distributed binaries doesn’t rely on promises from Meta.
[†] Source is always good to have, but it's insufficient.
That said, you seem to be refuting even that idea. While your reputation precedes you, and while I haven't been in the field quite as long as you, I do have a few dozen CVEs, I've written surreptitious side channel backdoors and broken production cryptographic schemes in closed-source software doing binary analysis as part of a red team alongside former NCC folks. I don't know a single one of them who would say that lacking access to source code increases your ability to establish a chain of trust.
Can you please explain how lacking access to source code, being ONLY able to perform dynamic analysis, rather than dynamic analysis AND source code analysis, can ever possibly lead to an increase in the maximum possible confidence in the behavior of a given binary? That sounds like a completely absurd claim to me.
There's a lot of background material I'd have to bring in to attempt to bring you up to speed here, but my favorite simple citation here is just: Google [binary lifter].
The source code is just a set of hints about what the binary does. You don't need the hints to discern what a binary is doing.
At a high level, what I'm fundamentally contending is that WhatsApp is less trustworthy and secure than Signal. I can have a higher degree of confidence in the behavior and trustworthiness of the Signal APK I build from source myself than I can from WhatsApp, which I can't even build a binary of myself. I'd simply be given a copy of it from Google Play or Apple's App Store.
Signal's source code exhibits known trustworthy behavior, i.e. not logging both long-term and ephemeral cryptographic keys and shipping them off to someone else's servers. Sure, Google Play and Apple can modify this source code, add a backdoor, and the binary distributed by Google Play and Apple can have behavior that doesn't match the behavior of the published source code. You can detect this fairly easily, because you have a point of reference to compare to. You know what the compiled bytecode from the source code you've reviewed looks like, because you can build it yourself, no trust required[1], it's not difficult to see when that differs in another build.
With WhatsApp, you don't even have a point of reference of known good behavior, i.e. not logging both long-term and ephemeral cryptographic keys and shipping them off to someone else's server, in the first place. You can monitor all the disk writes, you can monitor all the network activity. Just because YOU don't observe cryptographic keys being logged, either in-memory, or on disk, or being sent off to some other server, doesn't mean there isn't code present to perform those exact functions under conditions you've never met and never would - it's entirely technically feasible for Google and Apple to be fingerprinting a laundry list of identifiers of known security researchers and be shipping them binaries with behavior that differs from the behavior of ordinary users, or even for them to ship targeted backdoored binaries to specific users at the demand of various intelligence agencies.
The upper limit for the trustworthiness of a Signal APK you build from source yourself is on a completely different planet from the trustworthiness of a WhatsApp APK you only have the option of receiving from Google.
And again, none of this even begins to factor in Meta's extensive track record on deliberately misleading users on privacy and security through deceptive marketing and subverting users' privacy extensively. Onavo wasn't just capturing all traffic, it was literally doing MITM attacks against other companies' analytics servers with forged TLS certificates. Meta was criminally investigated for this and during discovery, it came out that executives understood what was going on, understood how wrong it was, and deliberately continued with the practice anyway. Actual technical analysis of the binaries and source code aside, it's plainly ridiculous to suggest that software made by that same corporation is as trustworthy as Signal. One of these apps is a messenger made by a company with a history of explicitly misleading users with deceptive privacy claims and employing non-trivial technical attacks against their own users to violate their own users' privacy, the other is made by a nonprofit with a track record of being arguably one of the single largest contributors to robust, accessible, audited, verifiable secure cryptography in the history of the field. I contend that suggesting these two applications are equally secure is irrational, impossible to demonstrate or verify, and indefensible.
[1] Except in your compiler, linker, etc... Ken Thompson's 'Reflections on Trusting Trust' still applies here. The argument isn't that source code availability automatically means 100% trustworthy, it means the upper boundary for trustworthiness is higher than without source availability.
I've been largely ignoring your sideline commentary about not trusting Meta and their other work outside of WhatsApp. Mostly because the whole thrust of my argument is that an app's security is confirmed by analyzing what the code does, not by listening to claims from the author.
Beyond that, I've been commenting in good faith about the core thrust of our disagreement, which is whether or not a lack of available source code disqualifies WhatsApp as a viable secure messaging option alongside Signal.
As part of that, I had to respond midway through because you put a statement in quotation marks that was not actually something I'd said.
Can you please explain how lacking access to source code, being ONLY able to perform dynamic analysis, rather than dynamic analysis AND source code analysis, can ever possibly lead to an increase in the maximum possible confidence in the behavior of a given binary?
This doesn't make sense, because not having source code doesn't limit you to dynamic analysis. I assumed, 2 comments back, you were just misunderstanding SOTA reversing; you got mad at me about that. But the thing you "never stated it wasn't" is right there in the comment history. Acknowledge that and help me understand where the gap was, or this isn't worth all the words you're spending on it.
I want secure messaging, not encrypted SMS. I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device. I want not losing my messaging history to not be a paid feature. I want to not depend on a shady crypto company to send a message.
I send long messages via Signal, typed on a desktop computer, all the time. (In fact, I almost exclusively use Signal through my desktop app.)
You don't have to use it like "encrypted SMS"! You're free.
> I want my messages to sync properly between arbitrary number of devices. I want my messaging history to not be lost when I lose a device.
OK. https://signal.org/blog/a-synchronized-start-for-linked-devi...
> I want not losing my messaging history to not be a paid feature.
I genuinely don't understand what you mean here. From https://signal.org/blog/introducing-secure-backups/
"If you do decide to opt in to secure backups, you’ll be able to securely back up all of your text messages and the last 45 days’ worth of media for free."
If you have a metric fuckton of messages, that does cost money, sure, but as they say:
"If you want to back up your media history beyond 45 days, as well as your message history, we also offer a paid subscription plan for US$1.99 per month."
"This is the first time we’ve offered a paid feature. The reason we’re doing this is simple: media requires a lot of storage, and storing and transferring large amounts of data is expensive. As a nonprofit that refuses to collect or sell your data, Signal needs to cover those costs differently than other tech organizations that offer similar products but support themselves by selling ads and monetizing data."
If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.
If you want to self-host your own backups (at your own cost), that's easy to do.
You can literally set up SyncThing to stream your on-device backups to your NAS, cloud storage, or whatever.
> I want to not depend on a shady crypto company to send a message.
Shady crypto company?
Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.
I checked! https://soatok.blog/2025/02/18/reviewing-the-cryptography-us...
Using it as something more than encrypted SMS requires persistent message history between devices.
> metric fuckton of messages
“More than 45 days” is a metric fuckton? Seriously?
> If you want Signal to host the encrypted storage, that costs money. If you don't want to pay Signal money, they provide 45 days of backup for free.
I don’t want Signal to store my messages. I want Signal to not lock in my messages on their servers, so I can sync them between my devices and back them up into my own backups.
> If you want to self-host your own backups (at your own cost), that's easy to do.
Except there’s no way to move it between platforms. I have more than one device.
> Are you referring to MobileCoin? That feature isn't in the pipeline for sending messages.
I don’t want shady crypto company to hold my data hostage, and there’s no way to store it on my hardware and then move it between platforms. That’s my problem with signal.
> A Synchronized Start for Linked Devices
It only properly transfers 45 days. You can’t have more than one phone. Phones are special “primary devices” and AFAIK you can’t restore your messages if you lose your phone even if you have logged-in Signal Desktop.
Signal is not holding you hostage.
I’ve already lost message history consistency because one of my devices was offline for too long. The messages are there on my other device, but Signal refuses to let me copy my data from one of my devices to another. Signal is, quite literally, worse at syncing message history than IRC — at least with IRC I can set up a bouncer and have a consistent view of history on all of my devices, but there’re no Signal bouncers.
The point is that whatever secure messenger you use, it must plausibly be secure. Email cannot plausibly be made secure. Whatever other benefits you might get from using it --- federation, open source, UX improvements, universality --- come at the cost of grave security flaws.
Most people who use encrypted email are doing so in part because it does not matter if any of their messages are decrypted. They simply aren't interesting or valuable. But in endorsing a secure messenger of any sort, you're influencing the decisions of people whose messages are extremely sensitive, even life-or-death sensitive. For those people, federation or cross-platform support can't trump security, and as practitioners we are obligated to be clear about that.
It’s important to me — as a user — that a communication tool doesn’t lose my data, and Signal already did. Actual practicioners keep recommending Signal and sure, I believe that in a weird scenario where my encryption keys are somehow compromised without also compromising my local message history, Signal’s double-ratchet will do wonders — but it doesn’t actually work as a serious communication tool.
It’s also kinda curious that while the “email cannot be made secure” mantra is constantly repeated online, basically every organization that needs secure communication uses email. Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?
Say more. Plenty of people use Signal as a serious communication tool.
> Openwall are certainly practicioners, and they use PGP-over-email: are they commiting malpractice?
They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.
It’s not malpractice to LARP: plenty of people love getting out their physical or digital toys and playing pretend. But if you’re telling other people that your foam shield can protect them from real threats, you are lying.
I did say more already. Maybe you believe in serious communication tools that can’t synchronize searchable history between devices, but I don’t.
> They, and other communities that use GPG-encrypted emails are LARPing, and it’s only fine because their emails don’t actually matter enough for anybody to care about compromising them.
Are we talking about the same Openwall? Are you aware what Openwall’s oss-security mailing list is? Please, do elaborate how nobody cares about getting access to an unlimited stream of zerodays for basically every Unix-like system.
https://oss-security.openwall.org/wiki/mailing-lists/distros
> Only use these lists to report security issues that are not yet public
> To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below.
The few jobs that actually care about this stuff, like journalists, do use signal.
Openwall doesn't get security via pgp, it gets a spam filter.
Something like this happens basically every time I try to use Matrix though. Messages are not decrypting, or not being delivered, or devices can’t be authenticated for some cryptic reason. The reason I even tried to use Element Desktop is because my nheko is seemingly now incapable of sending direct messages (the recepient just gets infinite “waiting for message”).
https://photos.goldstein.lol/share/OIgowBN4Wmi4zlm8DmDP0s8jH...