The best crypto protocol is useless if no one uses it.
I don't know if you're familiar with the Olvid app. Its cryptographic system has been audited and is used by the French state. It allows you to create accounts that are not linked to a phone number or email address, etc. Lot of great features for tech-savvy crypto enthusiasts.
The only problem is that you have to be physically present and scan a QR code on each client to add a contact. So it does prevent spoofing, but it's incredibly impractical. Setting up a group chat is a real challenge because all the participants have to have each other's keys. Nobody wants to revive the PGP parties
I can instruct a non-technical relative to install Signal. Installing Conversations and configuring the right account on the right server is another story.
Quicksy "advises you" to use OMEMO. It doesn't make OMEMO always-on.
That's the fucking bar you need to meet.
Hey cmon.. I do; but, like, mostly for fun, and for the ceremonial readouts of usernames / key fingerprints etc... a bit of demonic summoning vibe, it can be...
But in seriousness: yes again and again, people miss the good chasing the perfect.
Also (to grandparent comment iirc): Signal reproducible builds have existed for a while, fyi!
https://github.com/signalapp/Signal-Android/tree/main/reprod...
Pretty bold thing to say under a blog post written by actual (and respected) cryptographer.
>XMPP (...) uses the same encryption technology
It does not
https://soatok.blog/2025/01/21/too-many-people-dont-value-th...
Responsible Disclosure isn't a real thing.
> and intentionally harassed aswell as spread FUD about the Matrix project.
[citation needed]
I did not harass anyone. Nor did I "spread FUD."
Years ago, I wrote that I do not recommend Matrix after https://nebuchadnezzar-megolm.github.io was published. This was an opinion, but several people pressed me on it.
I followed it up with a first-pass review of libolm, and disclosed it to the Matrix security team. After 90 days, I blogged about it. I literally followed coordinated disclosure. I even shared the draft before it was public so they could be aware of what was written.
Afterwards, the Matrix devs admitted they knew about the side-channels in libolm for years and never bothered to fix them. That should alarm Matrix users more than my disclosure or criticism.
Nobody was harassed in any of this.
For anyone reading: Matrix didn’t bother fixing libolm’s sidechannels because instead we switched to a new Rust implementation at https://github.com/matrix-org/vodozemac - which is what the vast majority (installwise) of Matrix clients use. The mea culpa is that libolm should have been explicitly deprecated much sooner.
The entire point of Sealed Sender and their use of zero-knowledge proofs for group membership is so the server doesn't know who's talking to who, so they can't even selectively censor messages from one person.
Signal's way to validate that a session isn't man-in-the-middle'd is the same as XMPP: You have to validate the session's fingerprint in real life, or over another secure channel, by scanning each other's QR code, a procedure we'll refer to as "the QR thing".
Over more than five years of Signal usage, I personally did this exactly twice.
Now, we can start to imagine the typical Signal user.
Either we consider that I'm a minority and at least the vast majority of people do "the QR thing", so most/all sessions are secure from any man-in-the-meddling.
But then, you present the argument that XMPP is insecure because it can send plaintext. So this imaginary Signal user would be careful and privacy-inclined enough to use "the QR thing", but too careless to keep OMEMO on his XMPP client (where it's on by default in the vast majority) !?
I can't imagine this user. I fail.
The other way to reason about this is that, just like me, no one does "the QR thing". The vast majority of sessions are not protected against an MITM. Note that "the QR thing" is identical on XMPP, so all previous criticisms apply, except for a key difference...
On XMPP, servers are small. Trust is diluted, and in a lot of cases, you know personally your administrator, if you're not tech-oriented, because your administrator is the guy who told you about it.
Even when it doesn't matter, the server does matter a bit, eh?
Tell me you didn't read the article, without telling me you didn't read the article.
They're adding Key Transparency to keep themselves honest. Their specific implementation today (which is probably not final) was one of the final parts I reviewed:
https://soatok.blog/signal-crypto-review-2025-part-7/
If you're going to talk about this with profound ignorance, it's probably wisest to not do so while responding to a blog post that significantly spent time on the piece that debunks your whole premise.
Repeat after me: The server matters. A lot. Even if you don't want it to.
Yes, and furthermore, there's already built-in support for ledger monitors to ensure the honest and integrity of their log.
The whole point of Key Transparency is to keep the server honest. Publishing may be centralized, but verification is decentralized. This is literally a problem space I'm working in right now! https://soatok.blog/category/technology/open-source/fedivers...
> Repeat after me: The server matters. A lot. Even if you don't want it to.
The only thing the server can influence is availability:
1. Whether or not you can participate in the network to begin with (which is mostly to prevent spam, and is the only component you still need a phone number for today)
2. Deciding whether messages are delivered or not, to everyone.
Signal can't selectively censor users, they can only stop the operation of the entire service at once. Sealed Sender and zkgroup address this.
With key transparency, Signal couldn't even mislead users about which public keys belong to each user if they wanted to.
There is no other powers, besides basic availability, that the server needs to provide.
Just because you're used to technologies where the server has more power than the clients, and where some clients can continue to use OMEMO 0.3.0 in 2025 while the rest of the ecosystem is on 0.8.3, doesn't mean your experience is necessarily relevant here.
As noted elsewhere, Signal has offered reproducible builds since March 2016. If you care that much about about client security, why not check that yourself and blow the whistle if the binaries mismatch?
_edit_ spent some time on your blog (turns out I've done that before - recognised style as well as furry universe / ontology; nice feeling to return). Reading reasons for disliking AES-GCM (always liked this simplicity + auth-baked-in AEAD approach as a dev/architect/user of applied crypto)...
If you see this _edit_ - do you use any specific tools to generate various sequence / flow diagrams? anything besides mermaid (+ draw.io, I somehow never got rid of using this one in times of urgent need...)? Thanks :)
I believe it is bad form / in bad taste to arrogantly presume your questions and points about server trust (and etc.) are unique, not addressed, and create new challenges; without first reading the article which is the bare minimum required for this, IMHO.
Btw, depending on your threat model you may want to validate pubkeys / established session key / etc. using other side channels regardless of software, protocol and medium used.
But those two are completely unrelated to security. I mean a self hosted solution can be secure, but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable.
No it's not. If I could conditionally control if your messages are delivered, and when. Even if I can't see the contents, that's a huge security vulnerability!
Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
this is the first I've heard this, got a source to prove this is actually true?
> Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
That's not how threat models work, it's not 'more' risk. It's additional work. The risk is the same, signal has to do it, or 'you' have to do it. The risk and level of effort is the same. The only thing that changes is the direct responsibile party. Depending on configuration, it might reduce the risk if you can lower the number of parties you have to trust. I.e. I can verify my servers are up to date, but I have to just trust me bro, that signal's servers are always up to date.
If you block delivery of a message, you have no idea who it's for or from.
> Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.
I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers?
but I was thinking network based disambiguation
edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-...
Signal's server doesn't know who sent the message, since that information was Sealed.
Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code.
They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
I.e. is a sender able to prove that it's impossible for signal servers to do this?
See https://signal.org/blog/sealed-sender/ and https://eprint.iacr.org/2019/1416 if you'd like descriptions for the protocols I'm trying to describe in HN comments.
The "most likely" part does a lot of carrying here, and you made my point. The additional work self-hosting is not trivial in this space. Assuming you can either personally dedicate a LOT of time, or personally pay staff people to keep up vs a dedicated team working on this means that the threat model is inverted now.
I self-host a number of services, I'm very pro self hosting. I'm _VERY_ aware there is always a trade off between "I want this to work", "I don't have time to fix this regularly because I have a Job and Family and hopefully other hobbies besides self-hosting a service" and "I need to constantly update and apply changes that sometimes do not gracefully fall into automation or introduce breaking changes".
Now consider that communication is one service and add on self-hosting other services, and the additional updates and knowledge to support it.
Outside of the small group of people that dedicate themselves to hosting and managing their services, which excludes most USERS (its in the name) the threat model is indeed inverted.
You're saying this in response a blog post where I basically did an over-the-weekend audit of Signal's cryptography. I don't know if you understand the irony of that.
> Some proprietary messenger
It's literally GPL free and open source software
> that's hostile to 3rd party clients
I disagree with Moxie on his stance about XMPP + federation, as I wrote about here (relating to my plans to build E2EE for the Fediverse): https://soatok.blog/2024/08/28/introducing-alacrity-to-feder...
> aswell as also wanting my phone number
I dislike this as well, but since the introduction of usernames, it's at least no longer required to give strangers your phone number to converse with them.
> will never compete with tried and tested open source technology like XMPP.
The converse is true: XMPP+OMEMO do not qualify as a Signal competitor. I've outlined my reasoning in the linked post.
Until the entire ecosystem uses the latest version of the protocol, encryption is always on, and there is no plaintext fallback, XMPP is a poor solution for private communications.
> There is a reason military and government orgs use their own infrastructure.
Are you insisting that XMPP is "military grade encryption"?
I don't think that's the fair implication there, and I'd also hope you'd pull out "military grade" as a red herring, as meaningless marketing speak and ignore it instead of trying to trap someone using it. (unless it was a primary point they made, critical to their position, clearly not the case here)
Anything else is uninformed navel-gazing about the risk without understanding the subject.
> so they've basically got everbody's real names.
Based on the above as well as on the fact that having phone number does not by itself == real name PII / identity - claiming "so they've basically got everbody's real names" is not just overly dramatic but also patently false and disingenuous. :( I'm sure you did not mean to dissuade people, but c'mon. Generalising in such a way and then adding hyperbole does not help, imho.
Such an adversary can ask the phone company whose phone number a certain phone number is, and they will tell him.
No, not necessarily. In fact I'd claim that we should all use Signal so that usage of Signal would not imply any kind of user profile (would not rconstitute any kind of meaningful signal where one could infer what kind of user they are).
I do believe that there's a spectrum of users with a corresponding spectrum of appropriate threat models.
If my own threat model (that I felt I had to adopt) was particularly gnarly, I would (1) use Signal sandboxed / in a VM, tunnelling all traffic through Tor (e.g. Tor listens on socket exposed to VM so that there's no easy way to work around tunnel), and/or (2) if particularly gnarly - would set up pre-shared one time pads with counterparties where possible, and use them to authenticate further, perhaps encrypt further (maybe just encrypting a session key, to save most of OTP) - essentially definitely not deem Signal enough by itself.
Signal correctly focuses on privacy, not on anonymity. The wider your set of claims as to what kinds of properties (from the set of: privacy, anonymity, censorship-circumvention, etc.) you provide, the higher the probability you're going to screw up with one of these, I'd say. Better to combine several tools where possible if your needs require it.
I've explained in another comment but, it effectively hides who's actually communicating with who.
You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically.
There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections.
Almost all proper anonymous remailers have been shut down. What remains, Tor for example, are insecure parodies of an anonymous remailer, and this is justified to the users as being for the sake of speed, but makes the system useless for anonymity. Even Mixminion is insecure if you can observe the full network, since you can count the packets received by the clients and there aren't dummy packets.
I did, in fact, check it when writing TFA.
> You still have connect to them and deliver this to the signal servers. They'll have your IP and will know approximately where you are physically.
Okay, let's actually think this through.
You have millions of people using Signal. When you send a message, the message is encrypted such that only the recipient can decrypt the envelope to verify if you're even permitted to send to them. The only thing the server gets is an encrypted envelope and some 96-bit random string that tells the server where to send the envelope.
This 96-bit random string is derived from your profile key (which is also encrypted and, at minimum, rotates every time you block someone).
Let's assume Signal's server has been maximally pwned by the NSA to slurp as much data and metadata as possible in the most malicious manner logically possible. In this thought experiment, they will now log things that the server currently does not because of a government-mandated implant.
In this scenario, the NSA will learn: someone from an IP address send an encrypted envelope to an unknown recipient.
Later, they will learn that another user (and their IP address) accessed the same envelope when downloading it from the Signal server.
You might be sitting there, rubbing your hands, thinking, "Wow, we sure got them." Except that there are millions of Signal users, many whom share IP addresses over time, and you can't even be reliably sure if a given Delivery Token maps to a targeted recipient.
Furthermore, you can't reliably distinguish between 1:1 messages and group messages, due to how groups are implemented (see: zkgroup).
> There is no way to make this kind of thing secure without some kind of remailer system and without many peer-to-peer connections.
When you say "make this kind of thing secure", are you talking about hiding IP addresses and phone numbers from Signal's servers? Or are you suggesting what Signal is already doing is not possible in the first place?
Cryptography isn't magic. It is comprehensible to mortals.
We used a law in the EU requiring ISPs to keep track of this. It was determined to be illegal, so many ISPs probably don't store this information anymore, but I am sure that many do, and there can be other people-- maybe someone from another country that comes to your country gets jobs at ISPs to modify their software and make it do things he wants.
I don't know about this Salt Typhoon, but as I interpret it, there was an excellent secure system, and then people built some kind of front end on top of it so they could enter their orders into it, and then somebody compromised that front end and basically started getting all the data that the government could order to be gathered. I'm thinking that's going to include who has what IP.
I agree though, the complexity is maybe okay. It doesn't sound like a super terrible protocol or that involved. I suppose the description I saw of it felt more convoluted. At the same, I felt that the complexity of the presentation was hiding something, which I think might well be true-- it might even have been this simple fact that the central server still has every opportunity to determine who sends things to whom.
Public WiFi.
> I don't know about this Salt Typhoon, but as I interpret it, there was an excellent secure system
Hahahaha no. There was never an excellent secure system. Look at the past decade or so of SS7 attacks.
This taken together means there's no security with regard to contacts if the server or the network is compromised.
There are excellent solutions to this: dummy messages and remailing. Without those no system can ensure that contact information is kept secret.
The Signal devs claim they don’t want people distributing forks of the foss client that point at the official Signal servers, but they actually release it under a free software license, so you are free to do precisely that, and all they can do is complain.
The software is free software governed by the software license, and the API/service is governed by the ToS. Neither prevents alternative clients.