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