6 ms·

Signals threat model is fundamentally flawed. If you distrust Signal infrastructure and need E2E to secure yourself then having a closed client from Google Play

Signals threat model is fundamentally flawed. If you distrust Signal infrastructure and need E2E to secure yourself then having a closed client from Google Play or App Store in direct control of the developers ensures nothing. XMPP is much more safe and reliable and uses the same encryption technology as Signal, or even Telegram as it allows non-official clients that also support E2E. Signal is useless. That and the fact Signal doesn't even run on some devices, whereas XMPP or Telegram usually will.

some_furry 2y ago
https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/
- 999ear-pure 2y ago
  With XMPP I can run (and audit) eveything myself. You can't do this with Signal. Some proprietary messenger that's hostile to 3rd party clients aswell as also wanting my phone number will never compete with tried and tested open source technology like XMPP. There is a reason military and government orgs use their own infrastructure.
  - some_furry 2y ago
    > With XMPP I can run (and audit) eveything myself. 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-federated-cryptography/ 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"?
    - grayhatter 2y ago
      > 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)
    - alt187 2y ago
      You can't trust the server on Signal. Anything else, especially theoretical navel-gazing about plaintext fallbacks or make-believe audits of the client half of the system is inconsequential against the simple fact: You can't trust the server on Signal.
      - hmmm-i-wonder 2y ago
        You don't have to. Reproducible builds, audited E2E and the other technical details combine to remove the need to trust the server for anything other than availability. Anything else is uninformed navel-gazing about the risk without understanding the subject.
        impossiblefork 2y ago
        But the server on signal may store who communicates with whom. The most important information of all; and they can even connect that to phone numbers, so they've basically got everbody's real names.
        some_furry 2y ago
        You should take a closer look at Sealed Sender and the zkgroup stuff. I've explained in another comment but, it effectively hides who's actually communicating with who.
        impossiblefork 2y ago
        Neither of those have anything to do with that kind of security. The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is. 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.
  - mardifoufs 2y ago
    Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. 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.
    - grayhatter 2y ago
      > 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!
      - hmmm-i-wonder 2y ago
        You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. 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
        grayhatter 2y ago
        > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. 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.
poincaredisk 2y ago
>Signal is useless Pretty bold thing to say under a blog post written by actual (and respected) cryptographer. >XMPP (...) uses the same encryption technology It does not
- 999ear-pure 2y ago
  OMEMO was modeled around Signals encryption. And I don't think being "respected" makes a persons statement less or more worthy, assuming we don't take into account this same individual failed to follow responsible disclosure and intentionally harassed aswell as spread FUD about the Matrix project. Something which has been audited by Ukraine, France and other reputable organisations.
  - some_furry 2y ago
    > this same individual failed to follow responsible disclosure https://soatok.blog/2025/01/21/too-many-people-dont-value-the-time-of-security-researchers 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 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.
    - Arathorn 2y ago
      > Afterwards, the Matrix devs admitted they knew about the side-channels in libolm for years and never bothered to fix them. 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 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.
thefrozenone 2y ago
Would byte for byte build reproducibility address this?
- some_furry 2y ago
  That's been a thing since March 2016. https://github.com/signalapp/Signal-Android/tree/main/reproducible-builds https://github.com/signalapp/Signal-Android/tree/main/reprod...
  - thefrozenone 2y ago
    That's good to know. Given that, I don't understand the suspicion of Google Play (App Store, sure).
    - sudahtigabulan 2y ago
      Signal's reproducible builds are not maintained well. Many versions have been released without anyone noticing the mismatches, until a user reports it.
sneak 2y ago
The Signal service’s Terms of Service do not prohibit non-official clients, so anyone can build and run a Signal client from source. 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.
- 999ear-pure 2y ago
  Didn't they intentionally take down other Signal clients from Google Play? Although to play devils advocate they seem to have stopped being so aggressive. Still scary and concerning.
  - sneak 2y ago
    They did that because they were misusing the Signal trademark. You are not allowed to use their trademark when naming your fork.
  - Beretta_Vexee 2y ago
    They mainly reported false Signal clients. What was the purpose of these fake clients is more worrying than their removal.
alt187 2y ago
This is actually a very astute observation of what's wrong with Signal. You can never trust the server.
- soatok 2y ago
  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 2y ago
    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 2y ago
      > 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/ 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.
Beretta_Vexee 2y ago
XMPP is great, until you have to explain to granny how to use it. Signal isn't perfect, but I can just tell Granny ‘install Signal, it's like WhatsApp or all the other messaging apps’. 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
- zaik 2y ago
  I helped setting up Conversations / Monal on my grandparents phones and they have no issues sending messages.
  - Beretta_Vexee 2y ago
    My grandmother lives 700 km from my home, I can't be there every time she changes her phone or breaks something. I can instruct a non-technical relative to install Signal. Installing Conversations and configuring the right account on the right server is another story.
    - zaik 2y ago
      Maybe https://quicksy.im/ https://quicksy.im/ would work in that case. Easy to install like Signal, but it uses your phone number as a routable XMPP address. Unsophisticated users get easy onboarding and nobody else gets locked into some walled garden.
      - some_furry 2y ago
        This isn't good enough. Quicksy "advises you" to use OMEMO. It doesn't make OMEMO always-on.
impossiblefork 2y ago
Yes, and there is also no protection of who communicates with whom, which is basically the most important thing of all.

some_furry 2y ago

https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/

999ear-pure 2y ago
With XMPP I can run (and audit) eveything myself. You can't do this with Signal. Some proprietary messenger that's hostile to 3rd party clients aswell as also wanting my phone number will never compete with tried and tested open source technology like XMPP. There is a reason military and government orgs use their own infrastructure.
- some_furry 2y ago
  > With XMPP I can run (and audit) eveything myself. 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-federated-cryptography/ 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"?
  - grayhatter 2y ago
    > 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)
  - alt187 2y ago
    You can't trust the server on Signal. Anything else, especially theoretical navel-gazing about plaintext fallbacks or make-believe audits of the client half of the system is inconsequential against the simple fact: You can't trust the server on Signal.
    - hmmm-i-wonder 2y ago
      You don't have to. Reproducible builds, audited E2E and the other technical details combine to remove the need to trust the server for anything other than availability. Anything else is uninformed navel-gazing about the risk without understanding the subject.
      - impossiblefork 2y ago
        But the server on signal may store who communicates with whom. The most important information of all; and they can even connect that to phone numbers, so they've basically got everbody's real names.
        some_furry 2y ago
        You should take a closer look at Sealed Sender and the zkgroup stuff. I've explained in another comment but, it effectively hides who's actually communicating with who.
        impossiblefork 2y ago
        Neither of those have anything to do with that kind of security. The preparation process for sealed sender looks very complicated and iffy, but maybe someone has checked that the protocol is secure-- I don't see any reason for such a complicated procedure, and I see such complicated procedures as something which can only be intended to hide insecurity, but let's assume it is. 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.
- mardifoufs 2y ago
  Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. 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.
  - grayhatter 2y ago
    > 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!
    - hmmm-i-wonder 2y ago
      You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. 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
      - grayhatter 2y ago
        > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. 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.

poincaredisk 2y ago

>Signal is useless Pretty bold thing to say under a blog post written by actual (and respected) cryptographer. >XMPP (...) uses the same encryption technology It does not

999ear-pure 2y ago
OMEMO was modeled around Signals encryption. And I don't think being "respected" makes a persons statement less or more worthy, assuming we don't take into account this same individual failed to follow responsible disclosure and intentionally harassed aswell as spread FUD about the Matrix project. Something which has been audited by Ukraine, France and other reputable organisations.
- some_furry 2y ago
  > this same individual failed to follow responsible disclosure https://soatok.blog/2025/01/21/too-many-people-dont-value-the-time-of-security-researchers 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 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.
  - Arathorn 2y ago
    > Afterwards, the Matrix devs admitted they knew about the side-channels in libolm for years and never bothered to fix them. 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 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.

thefrozenone 2y ago

Would byte for byte build reproducibility address this?

some_furry 2y ago
That's been a thing since March 2016. https://github.com/signalapp/Signal-Android/tree/main/reproducible-builds https://github.com/signalapp/Signal-Android/tree/main/reprod...
- thefrozenone 2y ago
  That's good to know. Given that, I don't understand the suspicion of Google Play (App Store, sure).
  - sudahtigabulan 2y ago
    Signal's reproducible builds are not maintained well. Many versions have been released without anyone noticing the mismatches, until a user reports it.

sneak 2y ago

The Signal service’s Terms of Service do not prohibit non-official clients, so anyone can build and run a Signal client from source. 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.

999ear-pure 2y ago
Didn't they intentionally take down other Signal clients from Google Play? Although to play devils advocate they seem to have stopped being so aggressive. Still scary and concerning.
- sneak 2y ago
  They did that because they were misusing the Signal trademark. You are not allowed to use their trademark when naming your fork.
- Beretta_Vexee 2y ago
  They mainly reported false Signal clients. What was the purpose of these fake clients is more worrying than their removal.

alt187 2y ago

This is actually a very astute observation of what's wrong with Signal. You can never trust the server.

soatok 2y ago
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 2y ago
  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 2y ago
    > 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/ 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.

Beretta_Vexee 2y ago

XMPP is great, until you have to explain to granny how to use it. Signal isn't perfect, but I can just tell Granny ‘install Signal, it's like WhatsApp or all the other messaging apps’. 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

zaik 2y ago
I helped setting up Conversations / Monal on my grandparents phones and they have no issues sending messages.
- Beretta_Vexee 2y ago
  My grandmother lives 700 km from my home, I can't be there every time she changes her phone or breaks something. I can instruct a non-technical relative to install Signal. Installing Conversations and configuring the right account on the right server is another story.
  - zaik 2y ago
    Maybe https://quicksy.im/ https://quicksy.im/ would work in that case. Easy to install like Signal, but it uses your phone number as a routable XMPP address. Unsophisticated users get easy onboarding and nobody else gets locked into some walled garden.
    - some_furry 2y ago
      This isn't good enough. Quicksy "advises you" to use OMEMO. It doesn't make OMEMO always-on.

impossiblefork 2y ago

Yes, and there is also no protection of who communicates with whom, which is basically the most important thing of all.