[soatok]

The whole point of end-to-end encryption is that you shouldn't have to.

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.

[alt187]

Interesting. Who distributes my keys from me to my recipient? Is it someone in the middle? You can see where I'm going with this.

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?

[soatok]

> 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".

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.

[alt187]

Where will I find this elusive append-only log? Will it be provided by the server? Will the verification be automatic?

Repeat after me: The server matters. A lot. Even if you don't want it to.

[soatok]

> Will the verification be automatic?

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?

[wfn]

Thank you for your work and thanks for your immense patience answering mostly-already-addressed concerns of someone who has not bothered to even read the article. It's bad form; noble of you to answer (and hopefully useful for others / posterity).

_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 :)

[wfn]

Wasn't downvoting for the questions, but started downvoting these comments of yours because of your attitude + expectation that OP will answer questions that have in various ways already been addressed if you read the article.

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.